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I.  INTRODUCTION 


A  computer  simulation  is  the  representation  of  a 
mathematical  model  in  a  manner  that  allows  the  user  to 
examine  the  system  beinq  modeled  and  gain  further  insight 
into  the  inner  workings  of  ,  the  system.  Typically, 
simulations  fall  into  five  classes:  the  Dresentation  of 
unobservable  phenomena,  operator  training  models,  gaming 
models,  design  tools  and  models  of  systems  with  factors  that 
preclude  experimentation  on  the  system  itself  [Rahe  1972], 

Modern  computers  and  graphics  terminals  have  removed  the 
last  barriers  that  previously  dictated  all-digital 
simulations.  These  terminals  can  be  used  as  exceptionally 
fast  and  versatile  outDut  devices.  The  comouter  may  be 
eauipoed  with  a  grapnical  input  device  such  as  a  araphic 
tablet  enabling  the  system  to  be  used  as  a  drafting  device 
with  unique  prooerties  (Newman  and  Sproull  19731. 

The  comouter  system  intended  for  use  should  provide  on- 
line, hands-on  high-speed  computation  with  excellent 
displays  and  interfaces  to  external  hardware.  The 
application  of  graphical  support  to  war  gaming  adds  a 
dimension  previously  not  available  to  the  modeler.  The 
capability  to  visually  monitor  the  simulation  durina 
execution  provides  insight  into  the  system  being  modeled 
that  tabular  results  obtained  after  the  fact  can  never  hope 
to  attain.   Interactive  programming  allows   the   develooment 


of  applications  which  can  interact  with  a  user  and  enable 
him  to  control  the  functions  performed  and  the  data  operated 
on  bv  the  program.  The  modeler  may  now  interactively 
participate  in  the  simulation  and  at  critical  times  make 
decisions  that  will  create  changes  in  the  outcome  of  the 
s  i  mu 1  a t  i  on  . 

One  important  facet  of  interactive  programming  is  the 
aspect  of  man-computer  symbiosis.  By  achieving  a  very  close 
couoling  between  the  human  and  the  computer/ the  computer  may 
facilitate  formulative  thinking  and  allow  the  human  member 
of  the  oartnershio  to  particioate  in  making  decisions  and 
controlling  complex  situations  without  inflexible  dependence 
on  predetermined  programs  [Licklider  I960]. 

Any  system  devised  to  attain  such  an  interactive 
simulation  system  with  graphical  support  should  not  be 
hastily  thrown  together.  "Add-on"  suDoort  tends  to  overly 
complicate  and,  reduce  the  efficiency  of  the  existina  system. 
For  any  system,  the  principles  of  simplicity  and 
effectiveness  are  essential  to  the  usefulness  of  the  system. 
These  two  principles  often  comoete  with  each  other  [Smith 
1970],  In  this  light/  it  is  critical  that  to  support  any 
existing  or  planned  system/  a  careful  systems  analysis  and 
design  must  be  the  first  step  toward  implementing  that 
support.  This  added  effort  should  result  in  an  efficient/ 
effective  system  while  maintaining  maximum  flexibility  and 
simplicity.  In  the  rush  to  implement  a  major  system/  the 
emphasis   is  generally  placed  on  the  application  with  little 


cons i derst i on  given  the  human  factors  when  the  interface 
between  man  and  his.  proqram  is  implemented.  Human  interface 
is  desirable  at  setup  time  when  there  are  many  displays* 
options  and  parameters  for  a  user  to  control.  If  he  is  an 
experienced  user  he  does  not  want  to  be  forced  to  cycle 
through  all  the  options.  The  user  desires  only  enough 
promoting  information  to  change  those  options  necessary  to 
setup  and  execute  his  run.  No  matter  how  well  a  system 
performs*  it  will  be  little  used  if  it  is  difficult  to 
setup.  The  user  must  be  considered  first  and  effective 
man-machine  interface  dialoaue  will  oecome  a  major 
consideration,  as  important  as  the  application  itself. 

The  process  of  extending  an  existing  war  game  to  include 
interactive  functions  is  so  complex  that  programming 
productivity  techniques  must  be  plannea  and  employed  from 
the  onset.  These  modern  techniaues  have  proven  to  be 
successful  in  control  of  software  projects.  Such  techniques 
as  structured  design,  too-down  design,  top-down  proqramminq, 
modularization,  structured  programming  and  walkthroughs, 
chief  programmer  team  concepts  and  a  scheduling  methodology 
will  be  crucial  to  the  development  and  maintenance  of  an 
accept ab 1 e  model . 

This  study  considers  all  oossible  software  concepts  and 
explores  their  applicability  to  the  model.  Some  of  these 
that  could  Drove  to  be  useful  tools  are:  database  management 
systems,  SIMSCRIPT,  graphic  support  languages  and  either 
general  purpose  or  tailored  versions  of  operating  systems. 


Various  programming  lanauages  lend  themselves  to  war 
gaming.  The  advantages  of  a  high  level  language  are  well 
established  and  their  usage  is  Darticularly  significant  in 
the  area  of  programmer  productivity.  Because  each  of  these 
language  instructions  translates  into  10-20  lines  of 
documented  code*  the  daily  productivity  of  the  programmer  is 
increased  at  least  three  fold.  Jhis  increase  has  been 
demonstrated  in  numerous  studies  [Brooks  1975] .  High  level 
languages  also  contribute  to  lower  application  maintenance 
costs/  improved  documentation  and  design  through  their 
ability  to  allow  se 1 f -document i ng  variable  names/  new 
constructs  and  easier  imolementation  of  alaorithms  (stack 
and  gueue  manipulation  for  examole). 

SIMSCRIPT  is  an  examole  of  a  high  level  language 
especially  developed  for  simulations.  The  internal  functions 
of  SIMSCRIPT  such  as  the  event  scheduling,  queue 
manipulation  „ and  system  defined  variables  enhance  the 
desirability  for  using  it.  FORTRAN  subroutines  can  be 
readily  called  from  the  language  allowing  program  efficiency 
to  increase  by  emoloying  critical  code  in  the  form  of 
FORTRAN  subroutines.  The  current  version  of  SIMSCRIPT  II. 5 
was  written  in  SIMSCRIPT  II. 5.  This  fact  demonstrates  the 
versatility  of  the  language.  In  the  last  several  vears 
certain  develooments  have  improved  the  efficiency  of 
SIMSCRIPT.  Among  these  developments  was  the  move  from  the 
generation  of  FORTRAN  intermediate  code  to  direct  generation 
of  machine  code.   Additionally/  the  number  of  steos  required 
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to  compiler  link-edit  and  execute  a   SIMSCRIPT   program   was 
reduced,  shortening  compilation  time. 

This  systems  analysis  parallels  most  systems  analysis 
procedures  but  addresses  the  question,  "What  resources  do  I 
need  to  provide  the  desired  capabilities  given  only  the 
constraint  of  using  SIMSCRIPT  II. 5  as  a  base  simulation 
language"  versus  "How  can  I  design  this  system  to  run  on  a 
particular  comouter".  This  is  considered  the  appropriate 
approach  to  designing  a  system  which  truly  meets  the  neeas 
of  the  combat  modeling  community.  Figure  1.1  deDicts  the 
systems  analysis  procedures  followed. 

UNCONSTRAINED  SYSTEMS  ANALYSIS  STEPS 


usTr 
objectives 


PERFORMANCE 
CRITERIA 


IALTERNATIVES1 


EVALUATION 

OF 

ALTERNATIVES 


PREFERRED 
SOLUTION 


ANALYSIS 
OF 

'  PREFERRED 
SOLUTION 


FIGURE  1.1 


1  1 


The  first  and  key  element  of  this  systems  analysis  study 
was  the  identification  of  the  user's  objectives.  Without 
this  critical  action  the  entire  study  would  have  been 
meaningless.  The  objectives  fell  into  the  three  general 
areas  of  graphical  display  suDport,  simulation  of  the  battle 
area  and  the  capability  to  determine  the  status  of  the 
battle  or  any  of  the  components  of  the  battle  at  any  desired 
instant  of  time  during  the  simulation. 

Once  the  user's  objectives  were  determined?  the  next 
step  was  to  select  a  set  of  general  performance  criteria. 
Performance  criteria  are  the  key  to  measuring  the  degree  of 
success  in  attaining  the  objectives  of  the  user.  System 
performance  measures  must  be  considered  to  oroduce  an 
efficient  and  effective  system  for  the  entire  life-cycle. 
The  system  must  possess  the  ability  to  reflect  changes  in 
both  friendly  and  enemy  force  structures  and  tactics.  The 
data  reflected  by  the  display  devices  must  be  current  at  the 
time  of  display.  This  could  mean  that  the  simulation  would 
have  to  be  halted  until  a  signal  is  generated  by  the 
completion  of  the  display.  The  duality  of  the  data  base 
will  be  reflected  by  the  level  of  data  integrity  needed.  Tne 
size  of  the  data  base  must  be  such  that  only  necessary  data 
items  be  stored.  Any  abuse  of  this  will  surface  in  the 
response  time  for  any  display  invoked  and  the  overall  amount 
of  secondary  storage  reguired  for  the  data  base.  The  system 
was  designed  with  growth  in  mind  so  that  additional 
capabilities  may  be  accommodated  as  new  technology  develops. 
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As  tactics  and  force  structures  change*  the  system  must  be 
capable  of  easily  absorbing  these  needed  changes.  Response 
timer  another  performance  measure*  is  considered  to  be  from 
the  time  a  user  depresses  a  carriage  return  after  a  display 
request  until  that  request  is  satisfied.  From  other  studies 
[Sutherland  1*566]  response  times  of  greater  than  10  seconds 
are  not  desirable  since  the  human  mind  will  become  impatient 
after  such  a  long  waiting  period.  A  good  response  time  is 
usually  three  to  five  seconds. 

Alternative  designs  were  conceived*  each  possessing  the 
capability  to  provide  all  of  the  desired  functions 
identified  as  user  objectives  within  the  performance 
criteria  established.  Alternative  conceptual  designs  are 
defined  as  concepts  arrived  at  through  "dreaming"  with 
objectives  and  restrictions  in  mind.  In  order  to  attempt  to 
capture  the  latest  hardware  and  software  capabilities  and 
philosophys  and  incorporate  them  into  this  system,  a  certain 
amount  of  general  research  was  conducted  in  the  areas  of 
simulation*  interactive  graphics*  database  design  and 
implementation*  operating  systems  and  systems  analysis  and 
aes i  gn  . 

After  the  list  of  designs  was  consolidated  into  general 
concepts*  each  conceptual  design  was  evaluated  to  insure 
that  the  design  under  consideration  met  the  objectives.  The 
advantages  and  disadvantages  of  each  alternative  were 
determined.  This  reduced  the  list  to  only  feasibile 
solutions  to  the  problem. 
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Chaoter  II  briefly  discusses  the  history  of  war  gaming, 
the  evolution  of  .  STAR,  a  current  description  of  STAR  and 
proposed  enhancements  with  the  supoort  required  to  achieve 
them.  This  final  version  of  STAR  is  the  entire  reason  for 
this  thesis,  that  is,  the  design  of  a  system  to  reach  this 
goa  1  . 

Chapter  III  discusses  the  alternative  approaches  to  the 
design  of  a  suoport  system  for  STAR.  The  alternatives 
include  a  database  management  system,  an  operating  system,  a 
distributed  system  and  graohical  routines  imbedded  in  the 
simulation  program.  These  alternatives  are  described  and 
evaluated  as  to  their  individual  capability  to  implement  the 
system.   A  prefered  solution  was  then  chosen. 

Chaoter  IV  continues  with  the  analysis  of  the  ooerating 
system  needed  to  support  the  solution  from  chapter  III.  The 
basic  features  needed  to  suooort  STAR  are  described  and 
examples  of  their  use  are  given.  The  modules  of  STAR  not 
previously  written  are  outlined  to  give  guidance  in  future 
development  activity. 

Chapter  V  presents  the  results  of  the  analysis  of  the 
current  version  of  STAR.  This  chaoter  summarizes  tne 
findings  of  the  analysis  and  presents  modifications  and 
recommendations  that  will  lessen  the  storage  reauirements 
for  STAR  while  speeding  uo  the  execution  of  the  model. 

Chaoter  VI  contains  conclusions  from  this  thesis  and 
recommends  further  courses  of  action  to  achieve  the  desired 
end  produc  t . 
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II.  BACKGROUND 


A.  HISTORY  OF  WAR  GAMES 

War  games  are  nearly  as  old  as  organized  warfare  itself. 
Evidence  has  been  uncovered  that  indicates  the  use  of  games 
to  simulate  war  in  ancient  Egypt.  Progress  in  war  gaming  is 
marked  by  a  series  of  improvements  in  support  techniques 
available  to  the  user. 

During  the  latter  half  of  the  eighteenth  century  the 
Prussians  developed  an  increased  emphasis  on  warfare  as  a 
branch  of  applied  mathematics.  In  1780,  Helwig/  Master  of 
the  Pages  for  the  Duke  of  Brunswick,  invented  a  game  quite 
similar  to  the  modern  commercial  war  game.  The  aame  used  a 
modified  chessboard.  Terrain  was  represented  by  using 
combinations  of  1666  small  squares  tinted  in  various  colors. 
These  small  s'auares  were  grouped  onto  the  doara  as  terrain 
features.  In  1795  Georg  Vinturinus  modified  the  game  by 
constructing  a  map  board  of  an  actual  piece  of  terrain. 

In  1811  von  Reisswitz,  the  Prussian  War  Counselor  at 
Breslau,  transferred  the  war  game  to  a  sana  table  with 
terrain  modeled  in  sand  to  a  scale  of  1:2373.  In  1824  Army 
Lieutenant  von  Reisswitz,  Jr.  modified  his  father's  game  by 
transferring  the  game  to  a  realistic  mao-like  chart  with  a 
scale  of  1:8000.  An  umpire,  detailed  rules,  and  Drobability 
tables  were  also  introduced  bv  von  Reisswitz,  Jr.  The  size 
of   the   game  was  limited  to  approximately  four  square  miles 
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of  ground.  The  umoire  not  only  monitored  the  play  of  the 
game  for  compliance  with  the  rules  but  also  imoosed  two 
minute  time  slices  in  the  olayinq  of  the  game.  In  this 
manner  the  game  could  be  stooped/  as  desired*  and  a 
particular  two  minute  round  could  be  studied  in  detail. 

Further  improvements  occured  during  the  ninteenth 
century.  In  1866  Lieutenant  Wm  „  McC.  Little  suggested  a 
game  called  "Naval  viae  Game"  that  employed  blackboards* 
sheets  of  paper  or  charts*  or  maps  placed  on  tables  to 
illustrate  terrain.  At  about  this  same  time  celluloid  sheets 
or  overlays  were  introduced.  Information  drawn  on  these 
overlays  was  saved  as  a  historical  record  that  could  be 
analyzed  at  a  later  date.  This  idea  of  overlays  is 
attributed  to  the  Naval  War  College. 

Early  in  the  twentieth  century*  new  maps  preoared 
especially  for  mao  maneuvers  showed  large  tracts  of  actual 
terrain.  The  oldest  map  of  American  terrain  made  exoressly 
for  map  maneuvers  dates  from  1906.  This  map  of  Fort 
Leavenworth*  Kansas  includes  a  tract  approximately  four 
miles  in  width  by  six  miles  in  length  with  a  scale  of  1:5260 
and  a  contour  interval  of  ten  feet  [JCS  1969], 

In  the  Dost  WW-II  eraf  the  military  use  of  war  games 
became  increasingly  sophisticated  and  widespread. 
Sophistication  is  achieved  through  increasing  computer 
technology.  The  computer  allows  large  amounts  of  data  to  be 
stored  and  manioulated  without  tedious  book<eeoing  on  the 
part   of  the  user.   There  is  some  debate  over  the  usefulness 
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of  such  computer  simulations.  The  amount  of  data  generated 
is  so  great  that  it  can  overwhelm  the  user?  thereby 
undermining  the  very  reason  for  the  simulation. 

Modern  computer  war  games  have  seen  evolution  similar  to 
manual  games.  One  parallel  development  is  in  the  terrain 
model  associated  with  the  game.  Early  games  used  flat 
(imaginary)  terrain.  Terrain  advanced  to  idealized/  easily 
constructed  models  that  represented  no  identifiable  terrain. 
The  next  step  was  to  represent  real  terrain  through  the  use 
of  digitization  at  the  exoense  of  storage.  The  latest 
breakthrough  is  the  use  of  Darametric  terrain  capable  of 
modeling  any  real  terrain  in  a  size  never  before  imagined 
[Needles  1976] . 


B.  EVOLUTION  OF  SIMULATION  OF  TACTICAL  ALTERNATIVE  RESPONSES 
(STAR) 

A  significant  effort  is  currently  underway  at  the  Naval 
Postgraduate  School  to  develop  a  mid-resolution  combined 
arms  model  to  determine  both  hardware  and  training  measures 
of  effectiveness.  One  of  the  primary  goals  of  the  model  is 
to  achieve  an  acceptable  level  of  resolution  wrtile  assuring 
that  the  model  incuts  and  interactions  are  understood  bv  the 
military  decision-maker. 

Five  theses  comoleted  over  the  last  two  years  form  a 
basis  for  continuing  the  model  development.  A  Darametric 
terrain  model  was  developed  to  orovide  a  continuous  macro- 
terrain   representation.    This   representation   has  several 


17 


advantages  over  the  classical  approach  of  digitized  terrain. 
L i ne-of -s i gh t  computations  are  made  directly  from 
mathematical  relationships  as  opposed  to  the  time-consuming 
iterative  process  reguired  with  digital  terrain.  Mobility 
is  truly  continuously  as  ODposed  to  piecewise  linear 
technigues  used  for  digitized  terrain.  Terrain  can  Oe 
considered  as  a  parameter  of  the  combined  arms  analysis  as 
opposed  to  a  given.  By  appropriate  selection  of  inout 
parameters?  any  real  section  of  terrain  can  be  closely 
approximated  bv  the  oarametric  terrain  model.  Any  size 
terrain  sector  can  be  easily  generated  without  the  storage 
constraints  of  digital  terrain.  A  dynamic  smoke  module  has 
been  developed  and  operated  in  the  parametric  terrain  model. 

After  development  of  the  terrain  model?  two  theses  were 
aevoted  to  a  target  servicing  evaluation  of  blue  artillery 
against  a  red  ground  threat.  The  result  of  this  effort  was  a 
working  model  programmed  in  SIMSCRIPT  which  provides  dynamic 
representation  of  the  artillery  missions  down  to  the 
individual  element  level.  This  model  forms  the  basis  for 
future  enhancements  of  the  combined  arms  model.  An 
ammunition  supoly  model  was  developed  to  represent  the 
effects  of  such  parameters  as  interdictive  enemv  fire?  RAM- 
D?  truck  trips  oer  day  to  the  ammunition  supply  point?  truck 
replenishment  rate?  etc.?  on  the  number  of  rounds  available 
to  the  combat  vehicles  over  any  sustained  combat  period. 

Current  efforts  are  underway  to  incorporate  two-sided 
ground   and   artillery?   with   other   systems   as   close  air 
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support,  minefields,  cannon  launched  guided  projectiles, 
advanced  attack  helicopters,  air  defense,  etc.  These 
enhancements  will  be  made  to  the  blue  battalion  versus  red 
regiment  model.  In  addition,  a  dynamic  ammunition  resupDly 
model  is  being  developed. 


C.  CURRENT  DESCRIPTION  OF  STAR 

The  structure  of  STAR  is  trulv  hierarchial  in  that  it  is 
not  confined  to  any  specific  unit  size  or  configuration.  The 
parent-child  set  structure  of  SIMSCRIPT,  coupled  with  the 
flexible  parametric  terrain  model,  provides  the  reguired 
capabilities  to  realize  a  hierarchial  representation.  The 
level  of  resolution  is  orescribed  by  the  requirements. 

The  first  study  aoplication  of  STAR  was  in  support  of 
the  105/l20mm  ammunition  stowed  load  requirements  for  the 
XM-1  tank.  Initial  Droduction  runs  for  the  study  were 
conducted  for  a  blue  battalion  versus  a  red  regiment  in 
December  1978.  This  version  of  STAR  reDresented  all 
appropriate  ground  direct  fire  units,  two-sided  artillery, 
minefields  and  smoke.  Upon  completion  of  the  Phase  I 
battalion-level  production  runs  (on  a  10  x  10  km 
battlefield),  Phase  II  was  initiated.  The  result  of  Phase  II 
was  a  brigade-level  model  versus  a  red  division  on  a 
battlefield  approximately  50  x  50  km.  The  Phase  II  model 
will  be  capable  of  simulating  a  mu 1 t i -ecne 1  on  red  regimental 
attack  on  multiple  avenues  of  approach  in  both  the  Covering 
Force   Area   (CFA)   and  the  Main  Battle  Area  (MBA).  Extented 
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dynamic  play  of  ammunition  and  POL  resupply>  as  well  as  a 
significant  enhancement  of  the  tactical  representation  of 
battalion  engagements*  will  result  from  the  Phase  II  moael. 
In  addition,  artillery  units  will  be  directly  represented  on 
the  battlefield/  allowing  for  soecific  play  of 
counterbat t ery  and  counter  air-defense  fires.  Finally/  a 
dynamic  air-to-air  defense  model  is  being  developed  for 
Phase  II  model  representing  two-sided  air-to-air  engaaements 
for  both  fixed  and  rotary  wing  aircraft.  All  appropriate  red 
and  blue  air  defense  systems  will  be  olayed  in  the  model. 

The  SIMSCRIPT  language  was  selected  for  STAR  because  the 
language  was  designed  for  discrete  event  simulations.  The 
many  embedded  features  of  the  language  aive  the  proarammer 
wide  latitude  in  the  construction  of  event  flow.  The 
language  is  English-like  with  regard  to  the  construction  of 
commands.  The  heart  of  the  embedded  .simulation  facilities 
is  the  timer  f  which  is  used  with  certain  structural 
characteristics:  entities/  attributes/  sets  and  events. 
These  facilities  greatly  simplify  the  process  of  writing  a 
simulation  program  and  debugging  the  code.  This  is  further 
enhanced  by  a  compiler  which  provides  error  messages  and 
trace-back  routines  similar  to  WATFOR  and  rtATFlV  in  FORTRAN. 

The  structure  of  STAR  begins  with  the  concept  of  an 
entity*  An  entity  is  s i mo  1 y  a  representation  or  model  of  an 
item.  In  STAR  the  basic  entity  is  a  weapon  system 
representing  tanks/  TOwS/  artillery  pieces/  etc.  Any  of 
these  entities  may  be  brought  into   existance   by   a   simple 
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phraser  which  includes  the  name  of  the  entity.  For  example* 
the  phrase  CREATE  A"  TANK  reserves  a  place  in  memory  for  the 
entity  and  its  attributes  which  the  programmer  has  chosen  to 
call  TANK.  Associated  with  the  word  TANK  is  a  pointer 
variable  which  points  to  the  location  in  memory  where  TANK 
is  stored.  It  is  desirable  to  associate  certain 
characteristics  with  entities  after  they  have  been  created. 
These  characteristics  are  referred  to  as  attributes  ana  are 
affixed  to  an  entity  by  the  internal  bookkeeping  procedures 
of  SIMSCRIPT  (the  system)  or  are  placed  on  the  entity  by  the 
programmer.  Attributes  must  be  changed  by  the  programmer  as 
necessary  to  reflect  chanqes  in  characteristics.  Moreover, 
the  system  will  change  system-defined  attributes  as 
necessary.  The  concept  of  sets  in  SIMSCRIPT  is  very  useful 
when  it  is  necessary  to  grouo  entities  based  on  certain 
characteristics  or  in  the  construction  of  Queues.  In  STAR 
sets  have  been  used  primarily  to  oortray  membership  in 
organizations.  The  set  structure  mirrors  organizational 
structure  and  enhances  the  programmer's  ability  to  model 
unit  tactics  from  a  micro  to  macro  level.  An  entity  may 
belong  to  any  number  of  sets  and  the  entity  acauires  a 
membership  attribute  which  facilitates  identification  of  an 
ent  i  t y ' s  unit. 

An  extremely  flexible  method  of  filing  allows  entities 
to  be  ordered  in  a  set  by  ranking  of  certain  attributes  or 
by  a  simple  f i rs t -i n-f i rst -out  basis.  STAR  uses  the  latter 
system   for   most   apo 1 i ca t i ons .   The  set  logic  of  SIMSCRIPT 
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allows  this  to  be  easily  expanded  to  higher  level 
organi  zat  i  ons . 

Each  entity  in  STAR  is  modeled  to  reflect  a  flow  of 
activities  over  time.  In  particular*  each  entity  initiates 
or  undergoes  search,  detection,  target  selection,  firing  or 
impact.  These  five  events  are  scheduled  dynamically  based  on 
the  current  tactical  situation  or  an  appropriate  probability 
distribution.  When  an  event  is  scheduled  for  an  entity,  the 
SIMSCRIPT  timer  makes  a  record  of  the  time  that  the  event  is 
to  occur  (in  terms  of  overall  simulation  time)  and  the 
entity  for  which  the  event  has  been  scheduled.  Other 
characteristics  of  the  event  may  be  recorded  in  a  manner 
similar  to  the  assignment  of  attributes.  At  the  appropriate 
simulation  time,  the  event  is  executed  unless  cancelled  by 
some  logic  provided  by  the  programmer.  This  event,  when 
created,  would  be  filed  in  an  event  set  which  contained, 
among  other  thjngs,  the  time  that  the  event  is  to  take 
place,  the  entities  involved  in  the  event  and  the  event 
location  with  respect  to  other  scheduled  events.  When  X 
seconds  had  elaosed  from  the  current  simulated  time,  the 
event  would  take  place  and  the  conseauences  of  the  loqic 
written  in  the  event  routine  would  be  executed.  Event 
routines  may  in  turn  generate  other  events.  FIRE,  for 
example,  causes  the  scheduling  of  an  IMPACT  event.  IMPACT 
leads  to  the  scheduling  of  other  DETECT  and  TARGET . SELECT 
event  s . 

Event   routines    are         supoorted    by    a    number    of 
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computational  subroutines  in  STAR.  Subroutines  are  written 
in  both  SIMSCRIPT  and  FORTRAN  which  has  given  the  simulation 
a  great  deal  of  flexibility.  The  difficult  1 i ne-of -s i gh t 
calculations/  for  example*  are  accomplished  in  FORTRAN 
because  the  terrain  model  was  originally  written  in  FORTRAN. 
It  was  this  capability  to  call  FORTRAN  subroutines  that  made 
SIMSCRIPT  an  even  more  aopea 1 i ng" language .  Existing  FORTRAN 
routines  could  be  used  with  only  minor  modifications.  Other 
routines  more  closely  tied  to  the  entity  structure  of 
SIMSCRIPT  were  written  in  that  language.  The  routine  that 
updates  the  list  of  detected  targets  for  each  TANK  is 
written  in  SIMSCRIPT  to  take  advantage  of  the  dynamic 
dimensioninq  capabilities  of  the  lanauage  and  the  pointer 
variable  link  listing  techniques  available.  For  large  target 
arrays;  these  language  features  are  extremely  efficient  in 
reducing  memory  requirements. 


D.  PROPOSED  ENHANCEMENTS 

The  STAR  combat  model  currently  under  development  at  the 
Naval  Postgraduate  School  operates  in  batch  mode  on  the  IBM 
360-67  computer  in  the  W.R.  Church  Computer  Center.  It  is 
difficult  to  build  a  simulation  model  in  a  batch  processing 
environment.  Batch  processing  consumes  much  of  the  time  in 
developing  the  simulation.  Interactive  simulation  is  more 
economical  as  well  as  more  effective  in  problem  analysis. 
One  of  the  primary  goals  of  this  project  is  to  expand  the 
model  to  operate   in   an   interactive   mode   with   graphical 
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support.  Figure  2.1  depicts  the  goals  of  this  project.  The 
modeler's  ability  to  debug  a  simulation  is  greatly  enhanced 
by  the  interactive  capabilities  of  a  language.  Since  the 
simulation  user  is  constantly  engaged  in  upgrading  his 
simulation^  interactive  capabilities  are  an  important 
feature  of  any  support  system  [Mills  and  Phil  1977], 
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The  ability  to  actively  particioate  in  this  war  game  in 
an  interactive  mode  would  contribute  to  both  the 
productivity  and  the  flexibility  of  the  model.  In  an 
interactive  environment*  the  player  or  modeler  would  be  able 
to  input  decisions  that  would  aoproximate  those  made  by  the 
commander  on  the  battlefield.  Through  this  man-computer 
symbiosis*  the  ability  of  the  model  to  more  accurately 
reflect  the  actual  outcome  of  a  battle  would  be  attained. 
The  actual  flow  of  the  battle  could  be  altered  to  reflect 
realism  rather  than  rigid  programming  which  could  lead  to 
unforseen*  unrealistic  circumstances. 

A  primary  concern  in  the  desian  of  an  interactive 
simulation  system  should  be  ease  of  user  par t i c i oat i on  in 
the  simulation  during  execution.  To  facilitate  this  ease  of 
use*  an  aopropriate  interrupt  facility  is  necessary  to  allow 
for  suspension  of  the  orogram  at  a  given  point  in  the 
program  logic  and  for  the  transfer  of  control  to  the  user. 
The  interrupt  handler  should  be  flexible  enough  to  process 
any  appropriate  reguest  at  any  time  and  return  control  to 
the  Doint  of  the  interruption  uoon  completion  of  the 
handling  of  the  interruDt.  This  interrupt  facility  would  not 
only  allow  inout  to  the  model  and  output  from  the  model  but 
also  susDend  the  simulation  to  allow  detailed  examination* 
decision  making  and  synchronization  between  simulation  time 
and  wall-clock  time. 

The  model  should  operate  in  real-time  if  Dossible.  The 
term   real-time*   in  the  modeler's  sense  of  the  term*  is  not 
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entirely  critical.  In  modeling  t ermi no  1 ogy.  rea 1 -t i me  is  in 
the  sense  of  wall-clock  time.  One  minute  of  clock  time 
constitutes  one  minute  of  simulation.  If  simulation  of  a 
thirty-minute  battle  runs  in  thirty  minutes  of  wall  clock 
time/  the  simulation  is  said  to  run  in  real  time.  Real-time 
in  the  computer  science  vernacular  is  of  utmost  importance. 
A  computer  system  is  said  to  be  running  in  real-time  if 
there  is  a  comouter  orogram  and  some  other  orocess  running 
"in-steoM  in  such  a  way  that  the  associated  process  is  not 
caused  to  run  slower  by  the  comouter  program.  This  could  be 
exemplified  by  the  simulation  program  and  the  graohics 
display  orocess.  If  the  simulation  program  sufficiently 
slows  the  interactive  graphical  input  process  that  the 
inputs  are  received  after  they  were  needed  for  use  in  the 
simulation*  then  the  computer  system  is  not  running  in 
real-time.  The  interactive  caoability  of  the  model  will  be 
useless  if  the  inputs  are  not  entered  in  sufficient  time  to 
effect  the  outcome  of  the  battle.  It  is  this  real-time  that 
the  system  must  achieve. 

Facilities  are  needed  to  save  the  state  of  the  model  at 
any  time  by  executing  a  single  command.  Conversely*  a 
command  should  be  available  to  restore  the  simulation  to  a 
previously  saved  state  and  execution  resumed  from  there. 
Such  a  caoability  provides  the  ability  to  save  intermediate 
states  of  the  simulation  run  for  the  purpose  of  returning  to 
the  previous  points  in  simulation  time.  This  techniaue  is 
valuable   in   cases   where  an  unexpected  behavior  enters  the 
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simulation  or  an  important  behavior  was  byoassed  before  its 
presence  was  discovered  (Sohnle  1973J. 

Since  the  primary  puroose  of  the  game  is  to  function  as 
an  analytic  tool f  any  supoort  system  must  be  capable  of 
recording  all  interactive  decisions  for  use  in  duplication 
of  runs  with  alternate  modeling  parameters.  The  flow  of  the 
battle  should  also  be  recorded  in  order  to  allow  in  depth 
analysis  at  the  conclusion  of  the  simulation  run  if  desirea. 

There  has  been  little  imaginative  use  of  comouter 
graohics  as  an  input/output  tool  for  simulations.  Some  use 
of  simple  plotting  has  been  used  but  the  power  of 
interactive  graphics  is  relatively  untouched.  Interfaces  to 
graohics  languaaes  will  permit  the  modeler  to  provide  more 
meaningful  displays  for  the  simulation  user.  Input  Dy  way 
of  graphics  has  been  grossly  underestimated.  Special 
purpose  graphics  input  is  a  natural  means  of  getting  inout 
with  today's  interactive  graphics  devices. 

The  most  fundamental  caoability  of  the  prooosed 
graphical  support  package  is  displaying  maps  of  the 
battlefield.  The  standard  map  is  a  10  X  10km  contour  map. 
This  map  would  be  Dlotted  by  referencing  one  of  25  standard 
map  sections.  These  25  standard  map  sections  would  cover  the 
50  X  50km  battle  area •  By  selecting  one  of  the  numbers  from 
1-25,  the  approDriate  contour  map  would  be  drawn  using  the 
default  contour  interval  of  100  meters.  An  alternate  mode 
for  plotting  maos  would  be  orovided  to  allow  the  plotting  of 
larger   areas.   Larger   maps  are       required   to  monitor  such 
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missions  as  counter-battery  fire  or  long  range  surveillance. 
These  larger  plots  would  be  called  by  referencing  the  lower 
left  corner  and  the  upper  right  corner  utilizing  four  digit 
grid  coordinates.  Since  the  area  to  be  plotted  would  be 
larger  (or  smaller  if  so  desired)  a  contour  interval  must  be 
supplied.  Scaling  will  be  Derformed  as  a  function  of 
maximum  and  minimum  grid  coordinates  specified. 

The  contour  maps  orovided  are  the  background  for  several 
types  of  overlays.  These  overlays  may  be  selected  singly  or 
in  any  combination.  The  plotting  of  excessive  numbers  of 
overlays  may  lead  to  cluttering  of  the  display  screen  and 
should  be  avoided.  One  such  overlay  is  in  support  of  the 
dynamic  smoke  module  included  in  the  simulation.  The  smoke 
overlay  will  show  the  location  of  smoke  or  other  obscuring 
elements  such  as  fog  or  rain.  Density  of  the  smoke  is 
indicated  by  the  intensity  of  the  displayed  smoke.  As  the 
smoke  dissipates  the  intensity  decreases.  The  effect  of  wind 
on  the  smoke  is  shown  by  movement  of  the  smoke  display 
across  the  screen.  Results  of  patrols  and  reconna i sance 
flights  will  be  overlayed  on  the  basic  contour  map.  Targets 
detected  by  both  ground  and  aerial  observers  are  displayed 
while  under  observation.  The  results  of  active  ground 
detection  will  be  updated  as  reguired  by  movement  of 
elements.  The  results  of  aerial  reconna i sance  are  static  in 
nature  after  the  completion  of  the  flight.  Other  overlays 
include  the  display  of  road  networks/  towns/  obstacles/  both 
natural  and  man  made/  animation  of  firing  events/  receipt  of 
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enemy  fire/  nuclear  planning  aids  and  indirect  fire. 

Dynamic  route  and  position  selection  will  be  supported 
from  the  graphics  terminal.  By  utilizing  a  light  pen/  data 
tablet/  cursor/  track  ball/  joy  stick/  thumb  wheels  or  some 
other  type  inout  device/  the  player  should  be  able  to 
interactively  input  changes  or  supplimental  information  into 
the  model  during  execution.  The  graphical  supoort  package 
also  provides  for  the  monitoring  of  unit  movement  through 
the  use  of  Deriodic  uodating  of  the  current  unit  position. 
During  execution  the  modeler  can  select  the  level  of  the 
unit  to  be  plotted.  If  the  modeler  selects  a  unit  level 
other  than  individual  element/  the  plotting  of  the  unit  is 
performed  using  the  standard  military  symbol  for  the  unit. 

Dynamic  movement  on  the  battlefield  gives  additional 
realism  to  the  simulation  and  often  discloses  information 
that  words  cannot  convey.  Unit  movement  is  reDresented  as  it 
occurs.  The  .actual  firing  of  weapons  to  include  round 
flight  and  impact  enhance  the  picture.  Any  comoat  introduced 
visual  effects  such  as  smoke  from  exploding  rounds  is 
depicted  along  with  its  dissioation  and  drift.  One  of  the 
largest  benefits  of  displaying  unit  movement  is  havinq  a 
tool  to  debug  the  dynamic  route  selection  module  that  will 
be  develooed  for  STAR.  Unless  the  modeler  has  the  capability 
to  monitor  the  route  taken  by  an  element/  he  can  never  be 
certain  of  the  performance  of  dynamic  route  selection  or 
where  that  element  is  located. 

Another  analytic  tool  to  be  furnished  the  modeler  is  the 
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ability  to  draw  line-of-sight  (LOS)  fans.  These  LOS  fans  are 
used  to  aid  in  selection  of  positions  for  weapons  systems* 
radars  and  other  LOS  deoendent  systems.  Ana  1 y t i ca 1 1 y *  these 
LOS  fans  serve  to  verify  LOS  calculations  for  firing  events. 
The  LOS  fan  will  be  represented  by  shading  on  the  contour 
map*  the  heavier  the  shading  the  greater  the  visability.  A 
second  type  of  LOS  fan  will  "be  offered*  this  being  a 
compliment  display  that  shades  the  area  that  cannot  be  seen. 
The  support  system  will  incoroorate  an  inquiry 
capability.  Whenever  a  simulation  creates  significant 
output/  tl\e  statistics  collection  capabilities  of  the 
simulation  language  may  not  provide  the  modeler  with  the 
information  needed.  Statistics  collection  by  a  simulation 
language  is  often  too  general  and  if  more  aetail  is 
required*  a  dump  of  the  state  changes  of  the  model  must  be 
analyzed.  This  inquiry  capability  supoorts  post  execution 
analytic  analysis  bv  enabling  specific  information  to  be 
retrieved  and  thus  avoid  searching  volumes  of  data  to  obtain 
a  single  data  item.  This  feature  of  the  war  game  allows  the 
various  players  from  staff  sections  to  inquire  and  receive 
information  concerning  any  data  the  model  maintains  that  is 
normally  available  to  that  staff  member.  For  examole  the 
G-l/S-1  needs  information  concerning  command  strength* 
losses*  individual  and  unit  reo 1 acemen t s *  friendly  and  enemy 
prisoners  of  war  (POW)*  civilian  personnel*  safety* 
personnel  services*  graves  registration*  casulty  reporting* 
awards  and   decorations*   medical   supply   and   maintenance* 
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straggler  disposition  and  headquarters  movements  security, 
operation,  rear  command  post  location  and  visitors.  The 
G-2/S-2  is  concerned  with  recommending  essential  elements  of 
information  (EEI),  requests  for  target  acquisitions, 
surveillance,  reconna i sance ,  interrogation  of  enemy  PQWs, 
debriefing,  captured  enemy  documents,  signal  intelligence, 
intelligence  interpretation,  weather,  predicting  NBC 
fallout,  situation  maos,  counterintelligence,  recommendina 
proposed  areas  of  ooerations  to  the  G-3/S-3,  intelligence 
training,  aggressor  forces  if  employed,  civilian-military 
operations  and  camouflage.  The  G-3/S-3  is  tasked  with 
insuring  the  number  and  types  of  units  assigned  to  support 
and  accomplish  the  mission,  attachment  and  detachment  of 
units,  organizing  and  equip ing  units,  training,  preparing 
the  operational  estimate,  integration  of  fire  and  maneuver, 
basic  and  special  loads  for  weapon  systems,  priorities  for 
allocating  critical  resources,  coordination  and  use  of 
airspace,  designation  of  bivouacing  areas,  recommending 
general  location  of  the  command  post,  electronic  warfare 
activities,  communications  and  maintaining  a  current 
estimate  of  the  situation.  The  G-4/S-4  is  concerned  with 
matters  of  supply,  monitoring  the  distribution  of  supplies, 
supervising  the  distribution  of  critical  combat  weapons  and 
munitions,  recommending  prescribed  loads,  managing  special 
weapons,  procurement  and  storage  of  special  weapons, 
collection  and  disposal  of  excess  equipment,  maintenance, 
repair   parts,   evacuation   or   retrograde   of   unservicable 
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eauipment,  transportation,  refueling,  construction,  property 
control,  food  services,  use  of  POWs  and  civilians  and 
decontamination  operations.  This  data  is  available  in  a 
tabular  form  similar  to  figure  2.2. 


TABULAR  DISPLAYS 
"INGRES  FLAVOR" 


unit   !  position  !#rds  left!*rds  fired!   fuel 


atgts 


FIGURE  2.2 

The  graphics  oackage  will  include  the  capability  to 
represent  terrain  in  three-dimensional  form.  This  facility 
enables  the  modeler  to  verify  that  the  shape  of  the  terrain 
used  in  the  model  is  in  reality  a  true  representation  of  the 
actual  terrain.  Three-dimensional  terrain  plotting  also 
serves  to  verify  LOS  calculations  and  aids  in  selection  of 
routes  and  positions.  Through  the  use  of  three  dimensional 
terrain,  aircraft  flight  simulation  is  Dossible.  The  viewing 
screen  is  capable  of  displaying  terrain  as  seen  from  an 
aircraft.   The   display  includes  the  terrain,  vegetation  and 
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all  elements  located  on  the  terrain  being  traversed. 
Additionally  this  three-dimensioned  terrain  feature  can  be 
expanded  to  provide  360  degree  scans  from  any  point  selected 
by  the  user. 

The  use  of  color  in  graphical  displays  was  determined  to 
be  of  extreme  importance.  The  representation  of  red  and  blue 
forces  is  an  obvious  advantage.  The  ability  to  use  color  to 
represent  vegetation  lends  realism  to  the  display.  The 
number  of  items  to  be  represented  is  so  large  that  without 
color  it  will  be  difficult/  if  not  impossible,  to 
distinguish  features  displayed. 

A  report  writer  is  of  practical  importance  to  the 
analyst.  This  reoort  writer  will  be  highly  formatted  to 
provide  statistics  reguired  by  the  analyst .  The  user  will  be 
able  to  soecify  the  statistics  to  be  displayed  and  the  table 
will  be  generated  automatically.  Additional  hard  copy 
support  will  be  available  in  the  form  of  a  cooy  aevice 
attached  to  the  terminal  that  may  be  used  to  copy  the 
current  image  on  the  display  device. 

Any  qraphical  supoort  system  devised  would  not  be 
complete  without  providing  assistance  to  the  user  aurina 
execution.  Instructions  for  use  must  be  available*  on  call, 
at  any  time,  with  various  levels  of  detail  for  various 
levels  of  experience  in  playing  the  game.  This  type  of 
interactive  counseling  will  be  provided  in  the  form  of  a 
helo  function.  .  This  help  function  will  be  provided  for  two 
levels   of   expertise,   the  novice  and  the  experienced.   The 
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novice  user  needs  information  concerning  functions 
available*  their  formats  and  their  commands.  The  expert*  on 
the  other  hand*  requires  only  a  reference  to  the  commands 
available  since  he  is  familiar  with  their  formats. 

Certain  tutorials  and  guides  must  be  suDplied  to  the 
user.  Directions  for  position  selection  using  the  line  of 
sight  fans  must  be  readily  available  for  use  during  setup  of 
the  simulation.  A  military  symool  library  should  be 
included  with  the  descriptions  of  the  available  symbols  and 
the  method  of  placement  of  the  symbol  of  the  overlay.  This 
description  includes  details  of  how  the  computer  decides 
where  the  automatically  generated  symbol  is  placed.  Any 
graphical  support  provided  for  this  system  must  provide  for 
an  interactive  means  with  which  the  user  can  generate  the 
parametric  terrain  and  verify  it  against  the  actual  terrain 
or  a  map.  This  terrain  package  must  provide  not  only 
assistance  in  design  of  the  terrain,  but  also  the  capability 
to  record  the  parameters  selected  for  later  use  in  the 
simulation.  It  is  highly  desirable  that  the  user  have  the 
means  to  obtain  a  hard  copy  of  this  terrain  generation  for 
this  verification  process. 


E.  TYPES  OF  GRAPHICAL  DISPLAYS 

The  graphical  support  package  will  consist  of  three 
separate  types  of  applications  packages.  The  first  type  of 
support  is  provided  in  the  form  of  monitors.  These  monitors 
are   the   devices   that  provide  the  selective  terrain  plots. 
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The  terrain  plots  are  selected  by  the  user  and  displayed 
until  the  user  elects  to  either  terminate  the  display  or 
request  another  sector.  The  display  monitor  reflects 
current  unit  movement  located  within  the  terrain  sector. 
The  user  has  limited  control  over  functions  of  these 
monitors.  These  monitors  have  the  basic  function  of 
displaying  the  contour  maps.  The  user  will  be  able  to  select 
from  a  standard  set  of  10  X  10km  contour  maos,  or  he  mav 
specify  a  sector  using  grid  coordinates  and  the  desired 
contour  interval.  The  user  may  also  specify  the  unit  or 
element  to  be  displayed.  These  monitors  have  a  selective 
zoom  feature  to  allow  the  user  to  focus  on  a  given  area  in 
greater  det  a  i 1 . 

A  second  type  of  display  incorporates  the  inquiry  mode 
of  the  support  package.  These  displays  will  be  alpha- 
numeric terminals.  These  terminals  enable  the  various  staff 
players  to  inquire  about  personnel/  logistical  and  other 
routine  affairs  of  a  unit.  Levels  of  inauiry  are  controlled 
by  the  user.  The  terminal  initiates  a  hierarchical  search 
with  the  highest  level  unit  available*  giving  the  ODtion  of 
makinq  the  inquiry  at  this  level  of  resolution  or  displayina 
subordinate  units  at  a  level  one  unit  lower.  If  the  user 
elects  to  make  his  inquiry,  then  action  is  initiated  to 
determine  the  type  inquiry  from  a  menu  of  possible  choices. 
The  information  is  then  disDlayed  and  execution  continues. 
Should  the  user  elect  to  traverse  throuqh  the  hierarchy  in  a 
downward  direction,  the  monitor  will  display  the  subordinate 
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units  and  ask  the  user  to  indicate  the  unit  in  which  he  is 
interested.  This  .is  continued  until  the  user  reaches  the 
level  he  desires  and  the  inquiry  is  initiated. 

A  third  type  of  display  will  provide  the  function  of  the 
master  graphics  console.  This  console  is  fully  interactive 
and  accomplishes  all  dynamic  changes  and  selections  in  the 
program.  This  terminal  is  anticipated  to  be  larger  with 
greater  resolution.  The  caoability  for  drawing  in  three 
dimensions  is  realized  at  this  terminal.  All  graphical 
requests  are  originated  at  this  terminal  with  the  possible 
exception  of  the  inquiry  functions.  Inquiries  may  also  be 
initiated  at  the  aloha-numeric  terminals.  For  ease  in 
selection  of  the  function  to  be  performed/  a  menu  selection 
technique  is  used.  The  user  selects*  by  means  of  a  light-Den 
or  some  curser  positioning  device*  the  desired  ^unction  to 
be  performed.  This  initial  selection  leads  to  the 
fullfillment  of  the  user's  request  or  the  display  of  another 
menu.  In  addition  to  providing  the  executive  routine  which 
manages  the  execution  of  the  simulation/  the  monitor 
provides  the  ability  for  the  user  to  interact  with  the 
simulation  program  directly  from  the  terminal.  This  allows 
the  user  to  not  only  observe?  verify  and  record  data*  but 
also  interrupt  the  simulation  to  change  parameter  values  or 
modify  the  model  structure.  Figure  2.3  depicts  tyoes  of 
ai  spl ays . 
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III.  CONCEPTUAL  SOLUTIONS 

The  problem  at  hand  is  to  implement  graphical  suDoort 
and  inquiry  capability  to  an  existing  war  game  without 
serious  degradation  of  performance.  This  problem  is 
generated  by  the  merging  of  several  capabilities.  These 
capabilities  include  maintainina  a  real  time  environment* 
sharing  of  common  data  items  without  data  redundancy/ 
process  synchronization*  accurate  and  timely  displays  and 
interactive  oart i c i pat i on  by  both  the  user  and  programs. 
The  puzzle  is  to  fit  these  areas  into  a  comDlete  picture. 
This  puzzle  is  the  very  essence  of  this  thesis.  The  basic 
problem  has  been  simplified  by  one  assumption.  The  type  of 
computer  utilized  is  irrelevent  providing  it  is  capable  of 
performing  to  the  specified  standards.  The  question  of 
mini,  maxi  or  micro  implementation  revolves  around  the  state 
of  the  art  at  implementation  time  and  the  purpose  of  the 
comouting  system  itself.  If  this  simulation  system  is  to 
become  highly  portable*  then  the  preferred  choice  may  be  a 
microcomputer  due  to  its  low  cost  and  Dortability.  If  this 
simulation  system  is  to  run  "stand-alone"  on  a  dedicated 
system*  then  it  may  be  appropriate  to  develoo  the  system  on 
a  m i n i comDut e r .  If  this  simulation  system  is  to  share  time 
with  other  programs  in  a  multiprogramming  environment*  then 
the  approoriate  choice  may  be  a  large  mainframe  capable  of 
both    multiprogramming   and   mu 1 t i orocess i ng .   This   thesis 
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leaves  machine  choice  to  the  individual  implementer. 

Solutions  to  the  puzzle  fall  into  four  general  classes 
with  various  degrees  of  difficulty  and  Derformance 
standards.  These  choices  include  a  database  management 
system;  a  tailored  operating  system,  a  distributed  system 
and  graphic  subroutines  embedded  within  the  simulation 
itself.  Brief  descriptions  of  the  characteristics  of  tnese 
four  approaches  are  discussed  in  the  next  four  sections. 
Section  E  evaluates  each  aporoach's  ability  to  implement  the 
simulation  system.  The  preferred  solution  is  chosen  in 
Sect  i  on  F  . 


A.  DATABASE  MANAGEMENT  SYSTEM 

One  approach  to  the  oroblem  of  supolying  graphical 
support  to  the  STAR  model  is  through  the  use  of  a  database 
management  system.  A  database  management  system  is  a 
collection  of  software  procedures,  designed  to  facilitate 
access  to  a  data  base.  This  data  base  is  shared  by  diverse 
users.  In  this  approach  the  main  simulation  proqram, 
written  in  SIMSCRIPT,  would  act  as  a  high-level  language 
applications  program.  The  user  would  interface  with  the 
applications  program  through  the  use  of  any  standard 
alphanumeric  terminal.  The  graphics  routines  would  act  as 
other  high-level  language  applications  programs.  Since  a 
database  management  system  has  the  property  of  being  able  to 
present  the  same  data  to  various  users  in  differing  formats, 
the   applications   programmers  would  have  their  own  external 
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models  of  the  data  available  to  them  [Curtice  19761.  This 
differing  view  would  allow  the  graphics  programs  to  be 
written  in  some  language  other  than  SIMSCRIPT  since  at  this 
time  there  is  no  provision  for  graphical  support  in 
SIMSCRIPT. 

The  actual  data  that  is  being  manipulated  by  the 
applications  program  is  stored  fn  a  common  area  within  the 
computer  system.  The  function  of  the  database  management 
system  is  to  allow  the  sharing  of  the  data  and  create  data 
independence  to  allow  for  different  views  of  the  data.  It 
is  the  responsibility  of  the  database  administrator  to 
develop  and  maintain  the  schemes  allowing  this  mappinq  to 
occur  (Martin  1976]. 

Database  management  systems  must  interface  with  the 
operating  system  in  order  to  accomplish  the  actual  maooing 
of  data  into  memory.  The  operating  system  and  the  aatabase 
management  system  must  coexist/  but  this  does  not 
necessarily  Vimit  the  usage  of  a  database  management  system. 
Operating  systems  are  available  under  which  any  qiven 
database  management  system  may  operate.  There  is  an 
important  relationship  that  must  be  discussed.  Database 
management  systems  and  operating  systems  provide  the  user 
with  a  variety  of  common  functions.  The  database  management 
system  design  must  take  into  account  the  services  provided 
by  the  ooerating  system  in  order  to  minimize  cost  1 v 
duplication.  Some  of  the  most  common  services  provided  by 
ooerating   systems   include   process  manaaement/  file-svstem 
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support/  input  and  output  support  and  usage  measurement 
(Wiederhold  1977],  Some  operating  systems  also  provide 
facilities  for  sharing  of  data  segments  [Organi<  1972J. 

The  use  of  a  database  management  system  has  several 
advantages.  The  database  management  system  supports  multiple 
users  of  the  system  at  any  given  time.  Data  redundancy  is 
reduced  if  not  eliminated.  Applications  programs  are  data 
independent.  The  database  management  system  provides 
internal  safeguards  for  data  integrity  [Date  1977].  Post- 
execution  analysis  is  also  facilitated.  The  ability  of  a 
user  to  conduct  inguiries  is  simplified  by  the  adoption  of  a 
highly  tailored  data  manipulation  language. 

A  database  management  system  offers  a  broad  range  of 
facilities  for  organizing/  viewing  and  manipulatina 
information.  The  creation  of  data  tables  by  the  user 
reguires  only  a  minimum  knowledge  of  the  system.  Often  new 
tables  can  be  constructed  automatically  from  existing  tables 
on  the  basis  of  some  format  property  of  the  original  table 
[Fram  et .al  .  19771  . 

Typically/  data  manipulation  languages  are  written  in 
English-like  commands.  With  minimal  training/  a  novice  user 
can  do  useful  work  on  the  database  management  system  using 
the  data  manipulation  language.  Many  of  the  more  common 
commands  may  be  invoked  in  a  dialog  form  in  which  the  system 
prompts  the  user  for  additional  data  or  instructions. 

One  of  the  largest  disadvantages  is  the  addition  of  more 
overhead   and  hence  additional  execution  time.   Part  of  this 
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probem  may  be  overcome  by  the  design  of  a -compiled  database 
management  system  instead  of  an  interpreted  one  fftiederhold 
1977],  In  a  typical  database  management  system,  a  single 
user  command  may  result  in  the  performance  of  several 
physical  inout  or  output  operations.  Each  inout  or  output 
operation  must  be  initiated  by  the  central  orocessor  unit. 
In  a  multiprocessing  env i ronment t '  this  requires  the  seizing 
and  releasing  of  the  central  orocessor  unit  several  times  to 
carry  out  a  user  command,  therefore  a  significant  overhead 
due  to  task  switching  may  be  accrued.  The  order  of 
increased  complexity  introduced  to  the  system  by  the 
database  management  system  concept  must  be  considered. 
Database  management  systems  are  considered  by  many  to  be  as 
complex  as  some  operating  systems  and  hence  introduce  an 
additional  complexity  factor  over  and  beyond  the  operating 
system  and  the  basic  aoplication  programs.  Figures  3.1-3.2 
diagrams  the  roll  of  a  Database  Management  System. 
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B.  OPERATING  SYSTEM 

Modern  computer  hardware  is  very  powerful  and  may  be 
used  for  a  variety  of  tasks.  The  hardware  machine  is 
difficult  and  awkward  to  use.  In  order  to  simplify  usage  of 
the  bare  computer,  ooerating  systems  have  been  developed  to 
provide  a  more  hospitable  interface  with  users.  Operating 
systems  have  become  so  essential  to  efficient  comouter 
operation  that  many  peoole  view  them  as  inseparable  from  the 
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hardware  [Madnick  and  Donovan  1974], 

An  operating  system  is  a  collection  of  software  modules 
within  the  computer  system  that  control  the  operation  of  the 
computer.  These  modules  simplify  the  use  of  the  system, 
attempt  to  optimize  performance  and  resolve  conflicts  within 
the  system.  The  modules  manage  the  processors,  main 
storage,  secondary  storage,  input/output  devices  and  files. 
The  operating  svstem  performs  the  task  of  scheduling  the  use 
of  the  computer.  Sophisticated  operating  systems  increase 
the  efficiency  and  subsequently  decrease  the  cost  of  using  a 
computer. 

Operating  systems  vary  in  comolexity  from  simole  monitor 
systems  on  microcomputers  to  sophisticated  large  scale 
systems  capable  of  multiprogramming  and  multiprocess  ina 
while  providing  protection  and  interrupt  hardware. 
Regardless  of  the  complexity  of  the  system,  all  operating 
systems  provide  binding  for  processors  and  memories.  The 
operating  svstem  binds  data  to  physical  memorv  locations  and 
output  files  to  output  devices.  A  process  is  bound  to  a 
processor.  The  ability  to  perform  binding  is  fundamental  to 
all  operating  systems. 

Operating  systems  are  somewhat  distinct  in  their  ability 
to  provide  protection  mechanisms  [Graham  and  Oenning  19  72]  • 
The  first  level  of  protection  provided  by  operating  systems 
is  common  to  all  reliaole  systems.  This  is  the  protection 
of  the  operating  system  itself  from  destruction  by  tampering 
due   to   the   executing   program.    This   tampering   may   be 
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accidental  due  to  the  miscalculation  of  a  subscript  or  some 
similar  mistake/  or  it  may  be  an  intentional  effort  to 
sabatoge  the  system.  Whatever  the  source  of  the  tampering, 
the  operating  system  must  protect  itself.  A  significant 
difference  in  operating  systems  is  the  ability  to  protect 
classified  data  within  the  computer  system.  Some  computer 
systems  are  secure  only  in  the  dedicated  mode  where  only 
classified  material  is  allowed  in  the  computer  and  the 
security  perimeter  is  external  to  the  machine.  A  more 
complicated  but  more  useful  type  of  security  is  the 
multilevel  mode.  In  the  multilevel  mode  the  system  may  have 
various  users  with  varying  levels  of  security 
c 1  ass i f i cat i on f  all    competing    for    system    resources 

simultaneously  [whitmore  et.al.  1973].  The  securitv 
perimeter  is  internal  to  the  computer  and  provided  by  a 
mechanism  of  the  operating  system.  Access  permission  is 
determined  by  the  operating  system.  This  security  mechanism 
may  implement  a  desc ret i onary  or  nondesc ret i onary  policv. 

Some  operating  systems  are  capable  of  multiprogramming. 
In  a  multiprogramming  environment/  several  user  programs  are 
allowed  to  compete  for  system  resources  simultaneously 
tOennis  1965].  It  is  the  function  of  the  operating  system 
to  decide  which  job  will  be  run  at  any  given  time.  It  may 
be  possible  for  the  user  to  define  the  priority  of  the  job 
to  the  operating  system.  If  this  is  the  case  the  operating 
system  does  not  have  the  problem  of  enforcing  a 
desc ret i onary   priority   policy.     Determination    of    the 
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priority  may  be  left  to  the  ooerating  system.  Operating 
systems  use  various  criteria  for  establishing  priority. 
Methods  include  estimated  length  of  execution*  estimated 
storage  regui rement s ,  estimated  execution  time  and  estimated 
outDut  lines.  An  operating  system  may  also  use  a 
combination  of  these  two  technioues.  It  is  left  up  to  the 
operating  system  to  limit  the  number  of  programs  the  svstem 
will  accept  . 

Some  ooerating  systems  allow  multiprocessing  (Smith 
1977].  In  a  mu 1 t i process i nq  environment  the  computer  svstem 
has  multiple  processors,  each  capable  of  independent 
operation.  It  is  the  responsibility  of  the  central 
processor  unit  (CPU)  to  coordinate  or  synchronize  the 
functioning  of  the  processors.  In  a  system  such  as  this  it 
will  oe  possible  for  one  processor  to  be  performing 
calculations  while  another  processor  is  controlling  output 
to  the  line  printer. 

The  ooerating  system  not  only  provides  memory  management 
in  the  form  of  binding  but  also  is  capable  of  creating 
virtual  memory.  Virtual  memory  allows  the  address  space  of 
the  program  Peing  executed  to  be  either  greater  than  or  less 
the  the  physical  memory  of  the  machine.  Utilizing  this 
virtual  memory/  the  user  need  not  be  limited  by  the  physical 
size  of  the  main  memory  (Denning  19701. 

Another  feature  of  operating  systems  is  their  ability  to 
handle  interrupts.  Through  the  use  of  an  interrupt  handler, 
the  operating  system  may  accept   an   interrupt,   process   it 
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according  to  the  instructions  in  the  interrupt  handler  and 
return  execution  to  the  program  in  progress  at  the  point  of 
the  interrupt.  Operating  systems  have  system  defined 
interruDt  handlers  but  many  have  provisions  for  the  user  to 
define  his  own  interrupt  handlers. 


C.  DISTRIBUTED  SYSTEM 

A  distributed  system  is  a  computer  system  composed  of 
multiple  central  processors  that  cooperate  in  problem 
solving.  These  CPU's  may  be  spread  ever  many  miles  or 
located  in  the  same  room.  In  order  for  the  distributed 
system  to  function,  coordination  between  the  processors  is 
accomplished  by  a  distributed  operating  system. 

The  problem  of  extending  the  execution  time  of  the  model 
might  be  alleviated  by  the'  concept  of  a  distributed 
computing  system  composed  of  one  comDuter  to  process  the 
simulation  portion  and  maintain  a  master  data  base  and  a 
smaller  computer  providing  the  graphics  and  inauiry 
capabilities.  A  distributed  system  has  the  chacteristic 
that  the  functions  are  distributed  or  spread  over  multiple 
CPU's  each  designated  to  handle  a  particular  function.  This 
approach  becomes  advantageous  by  using  a  second  processor  to 
reduce  the  work  load  of  the  main  CPU.  Consider  the  case  of 
a  front-end  processor  connected  to  a  main  processor  as 
indicated  by  figure  3.3. 
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FIGURE  3.3 


The  front-end  processor  controls  the  interface  with  the 
user.  Graphical  displays  and  user  command  interpretation 
including  editing  are  performed  on  the  front-end  processor. 
This  allows  the  power  of  the  main  processor  to  be  devoted  to 
the  computation  bound  simulation  functions.  In  this  case 
the  main  processor  woulo  have  to  oass  the  required  display 
data  to  the  graphics  processor  as  needed.  Assuming  that 
this  would  take  a  small  amount  of  time  unaer  CPU  to  CPU 
communication  with  a  communication  line  of  high  transfer 
rate   equal   to   the   slower  rate  of  the  two  processors/  the 
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main  processor  could  continue  to  simulate  while  the  graphics 
processor  generates  the  display  list  and  causes  the  display 
to  occur.  This  would  have  the  effect  of  halting  the 
simulation  for  only  a  minimum  time  frame  and  thereby  not 
significantly  degrade  the  system.  Should  it  be  desirable  to 
stop  the  simulation  for  some  update  of  information  from  the 
graohics  processor,  an  interrupt  could  be  generated  by  the 
graohics  processor  and  sent  to  the  main  processor  which 
would  then  halt  the  simulation  to  receive  the  uDdate.  The 
problem  of  maintaining  data  integrity  emerges  from  the 
aforementioned  situation.  There  is  no  way  to  determine  if 
the  data  to  be  changed  exists  at  the  time  of  uodate  or  if 
the  data  displayed  is  current.  This  problem  will  have  to  be 
resolved  by  generating  an  uodate  request,  displaying  the 
current  status  of  the  battle  area  and  then  updating  the 
data.  This  must  be  handled  through  some  automated  means  so 
that  the  user  is  not  confronted  with  the  Droblem,  he  has 
enough  to  be  concerned  with  without  the  system  comolicatinq 
the  situation  for  him. 

The  distributed  system  functions  as  follows.  First  there 
must  be  established  priorities  that  each  CPU  follows.  For 
instance,  on  the  simulation  CPU,  communication  between  CPU's 
has  a  higher  priority  than  the  simulation  and  can  be 
represented  by  the  following  Dseudo  code, "while  (not 
communicating)  do  simulation".  This  action  will  give 
priority  to  CPU-CPU  communication,  allowing  the  user's 
inquiries   to   be   answered   more  raoidly.   The  graphics  CPU 
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continuously  tests  the  terminals  for  the  indicator  that   the 

user   desires   to   perform   some  function.   This  can  be  also 

accomplished    through    an    interrupt    mechanism.     Upon 

identification   of   the  user's  desired  function,  an  argument 

list  is  constructed   in   conjunction   with   additional   user 

supplied  data/  if  required*  and  an    interrupt  is  generated  to 

the  simulation  CPU  indicating  that  the  graphics  CPU   desires 

to   communicate.    Upon   receipt   of   the   argument  list  the 

simulation  CPU  stops   the   simulation,   stores   the   machine 

state  and  executes  a  "case"  structure  similiar  to: 

sw  i  tch(funct  ion-id) ; 
{ 

case(t):  terrain  information; 
case ( i ) :  i  nqui  ry ; 
case (u) :  uoaate? 

• 

} 
passing  back  to  the  graphics  CPU  any  resultinq   information. 
The  graphics  CPU  now  processes  the  information  received  from 
the   host   CPU   and   continues    the    function    originally 
identified  by  the  user,  such  as  producing  a  display. 


D.  EMBEDDED  GRAPHICS 

The  simplest  and  perhaps  the  most  direct  implementation 
of  the  desired  capabilities  is  the  execution  of  the  graphic 
capability  from  a  direct  subroutine  call  from  the  SIMSCRIPT 
simulation  program.  Figure  3.4  depicts  the  embedded  graphics 
approach . 
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There  are  several  advantages  to  this  approach.  The  graohics 
package  can  be  developed  seoarately  from  the  simulation 
model >  keeping  in  mind  that  necessary  parameters  required  bv 
the  display  must  be  Dassed  from  the  simulation  program  to 
the  graohics  subroutine.  A  simple  driver  could  minic  the 
functions  of  the  call  to  the  graphics  routine  during  the 
development  of  the  graphics  package.  In  the  same  way* 
should  the  graphics  subroutine  provide  the  interface  with 
the  user  for  the  interactive  oortions  of  the  models  certain 
parameters  would  have  to  be  returned  to  the  simulation 
program.  These  oarameters  must  define  the  type  of  function 
that  the  user  desires  to  oerform  along  with  any  function 
parameters  reauired.  The  values  of  the  parameters  could  be 
established   through   interpretation  of  light  pen  input  from 
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the  user.  This  interpretation  could  take  the  form  of  a  CASE 
or  nested  IF  type  structure  where  parameter  values  would  be 
established  from  an  interpretation  or  series  of 
i nt eroret at i ons  of  the  light  pen  incut.  Once  the  parameter 
list  is  formed  the  graphics  subroutine  is  called. 

There  are  disadvantages  to  this  concept.  Due  to  the 
nature  of  subroutine  calls*  the  action  of  the  simulation 
program  is  at  a  standstill  until  the  execution  of  the  call 
is  comoleted.  This  will  increase  the  execution  time  of  the 
simulation  program  and  thereby  increase  the  wall-clock  time 
reguired  to  simulate  any  given  battle.  This  problem  ceases 
to  retain  great  importance  if  it  is  desirable  that  the 
simulation  be  halted  to  allow  any  update  information  to  be 
passed  to  the  simulation  process  and  thus  maintain  data 
i  nt  egr  i  t y . 

Because  data  integrity  is  a  reguirement  of  the  system, 
the  graphical  displays  must  be  capable  of  depicting  the 
exact  state  of  the  simulation  upon  the  display  device.  To 
change  the  route  of  march  of  a  Darticular  unit  or  element 
that  item  must  be  locatea  in  the  depicted  position  at  the 
time  of  the  update  or  the  exact  position  must  be  known  to 
t  he  user. 


E.  EVALUATION  OF  ALTERNATIVES 
1.  Common  Considerations 

There  are       several   items   that   are   common   to   all 
approaches.    Included   in   these  items  are    the  use  of  color 
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displays,  hard  copy  devices  and  the  treatment  of  static  data 
such  as  contour  maps.  Hard  copy  devices  are  required  to 
record  selective  displays  upon  command  of  the  user.  Contour 
maps  are  thought  of  as  any  reauired  data  to  enable  a  rapid 
draw  of  the  desired  area  of  terrain.  Once  the  parametric 
terrain  data  is  constructed*  prior  to  the  simulation 
execution  and  during  some  system  initialization  Drocedures, 
there  is  no  need  for  the  simulation  process  to  have  access 
to  it  since  the  simulation  routines  comoute  any  required 
terrain  data  dynamically  during  execution.  There  is  only  the 
need  to  have  this  data  available  to  the  graphics  display 
routines.  The  impact  of  a  hard  copy  device  upon  the 
solution  is  seen  as  device  deoendent  and  therefore  not  of 
concern  in  the  selection  process.  In  the  same  manner  the 
method  of  drawing  contour  maps  is  device  dependent  and  the 
use  of  color  is  independent  of  implementation.  These  two 
factors  are  also  omitted  from  the  evaluation  orocess.  This 
evaluation  focuses  on  the  ability  or  inability  of  the 
alternative  to  support  the  simulation,  evaluating  failures 
on  the  lowest  possible  level. 

2.  Database  Management  System 

In  the  database  management  system  approach/  the 
simulation  program  assumes  the  role  of  a  high-level  1 anquage 
applications  program.  All  graohical  routines  except  the 
inquiry  program  are  also  hiqh-level  aoplications  orograms. 
The  inquiry  program  is  an  aoplications  program  written  in  a 
tailored  data  manipulation  language. 


54 


A  database  management  system  is  designed  to  allow  the 
sharing  of  data  and.  e 1 i mi nat e  data  duplication.  Through  the 
design  of  appropriate  schemas/  the  database  designer  is  able 
to  present  each  apolications  programmer  with  an  indeoendent 
view  of  the  data  and  allow  the  orogrammer  to  access  any  data 
within  the  data  base.  This  aoproach  presents  a  problem  with 
multiple  users  attemoting  to  write  data  simultaneously. 
This  problem  can  be  minimized  throuah  careful  design  and 
judiciously  granting  write  access  to  shared  data.  Should 
two  users  desire  to  write  data  to  the  same  file/  the  last 
copy  written  will  prevail. 

The  recording  of  dynamic  events  presents  a 
significant  problem  to  the  dataoase  management  system 
approach.  The  ability  of  the  system  to  accept  ana  store 
input  data  from  the  user  is  routine  to  a  dataoase  system. 
Anything  that  can  oe  input  and  stored  may  also  be  recorded 
on  secondary  storage  media.  The  significant  problem  arises 
when  the  machine  state  must  be  saved.  Only  the  operating 
system  has  the  capability  to  monitor  and  modify  all  the 
registers  in  the  machine.  For  the  database  management 
system  to  save  the  machine  state/  close  cooperation  with  the 
operating  system  is  required.  When  it  is  desired  to  return 
to  a  decision  Doint  to  resume  execution  with  another 
decision/  the  database  management  system  must  relinauish 
control  to  the  operating  system  while  the  operating  system 
restores  the  values  of  the  variables  and  the  machine  state. 

Flexibility   of   play   will   require    the    database 
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management  system  to  maintain  some  mechanism  to  generate  the 
appropriate  data  structure  for  the  level  of  play.  The 
flexibility  of  play  is  not  an  insurmountable  oroblem  but  the 
mechanism  to  achieve  this  goal  may  be  auite  complicated. 
The  flexibility  of  display  will  be  quite  easily  attained 
since  disDlay  is  dependent  only  on  the  data  stored  once  the 
data  structure  for  storing  the  data  has  been  created.  The 
ability  to  store  various  force  structures  must  also  be 
attained  by  some  dynamic  means  since  the  actual  size  of  the 
data  structure  reauired  will  not  be  known  until  run  time. 

The  degree  of  interactive  orogramming  attained  bv  the 
database  management  system  will  vary  from  routine  to 
routine.  The  inquiry  routines  will  have  the  full 
interactive  characteristics  of  any  database  management 
system.  The  programs  written  in  high-level  languages  are 
limited  by  the  degree  of  interaction  provided  by  the 
corresponding  languages.  The  database  manaaement  system  has 
no  means  of  incorporating  interrupt  driven  orocessing. 
Interruot  driven  processing  requires  action  by  the  operating 
system  and  therefore  a  close  relationship  between  the 
database  management  system  and  the  operating  system. 

The  database  management  system  approach  will 
adversely  affect  the  real-time  capability  of  the  program. 
Overhead  in  a  database  management  system  is  extensive.  The 
desirable  trait  of  data  independence  reauires  the  additional 
cost  of  address  translation.  Various  references  to  the  same 
data    element    require    the   system   to   translate   these 
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references  into  the  same  physical  memory  location. 
Additional  overhead  in  execution  time  is  reauired  by  the 
necessity  to  translate  or  compile  input  requests  during 
execution. 

The  report  writer  is  facilitated  by  the  database 
management  system  approach.  The  database  design  allows  for 
the  user  to  request  information  in  a  standard  format  and 
have  it  displayed  for  him  on  the  screen.  Any  information 
stored  may  be  displayed  as  well  as  any  combination  of  data 
items  that  may  be  created  using  relational  calculus  or 
standard  boolean  operators. 
3.  Operating  System 

Under  the  operating  system  concept,  the  simulation 
program  becomes  one  of  many  in  a  mu 1 t i orogramm i ng 
environment.  The  graphics  routines  are  organized  into 
programs  with  related  functions.  These  graphics  programs 
become  additional  programs  that  will  compete  with  all  other 
programs  for  system  resources. 

The  problem  of  sharing  files  is  not  significant  to  an 
operating  system  that  uses  segmentation.  Any  progran 
division  that  is  important  enough  to  be  named  may  be  created 
as  a  segment.  In  a  system  supoorting  this  seqment at i on ,  any 
segment  may  be  addressed  by  potentially  any  processor.  By 
careful  desianation  of  the  ability  to  read  and  write  to  a 
given  segment,  it  is  possible  to  allow  a  segment  that  is 
responsible  for  a  file  to  create  the  file  and  to  allow  a 
segment  that   must   use   that   data   for   display   or   other 
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purposes  to  access  the  data  and  use  it.  These  segments  that 
are  sharing  the  data  need  not  be  in  the  same  program.  The 
programs  need  only  be  active  at  the  time  of  sharing  of  the 
data.  One  potential  problem  may  arise  if  more  than  one 
segment  is  allowed  to  write  to  any  one  data  segment.  In 
this  case  the  last  segment  to  write  will  be  the  segment  that 
dictates  the  data  value  written.-  By  careful  1  design  of  the 
programs  involved/  this  problem  may  be  made  insignificant. 

The  ability  to  record  dynamic  events  such  as 
decisions  by  the  user  and  simulation  status  present  no 
significant  problem  for  the  operating  system.  At  the  time 
the  user  inputs  his  decision,  the  operating  system  needs  to 
write  the  input  data  into  the  aooroDriate  area  in  memory  to 
affect  the  simulation.  At  this  same  time  the  operatina 
system  will  make  a  copy  of  the  decision  information  along 
with  the  machine  state  and  any  pertinate  variable  values 
before  the  decision  is  made.  This  additional  information 
may  be  written  to  some  secondary  storage  medium  for  use  at  a 
later  time.  At  a  later  time  when  it  is  desired  to  return  to 
a  given  decision  point  and  change  or  modify  the  previous 
decision,  the  operating  system  has  all  the  information 
needed  to  restore  variable  values  and  restore  the  machine 
state.  Execution  may  then  resume  from  the  point  of  decision 
rather  than  reguiring  the  entire  simulation  to  be  executed 
agai  n . 

In  the  area  of  flexibility,  the  operating  system 
approach   presents  no  problem.   It  is  the  normal  function  of 
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some  operating  systems  to  allocate  storage  for  problem 
elements.  At  execution  time  the  ooerating  system  will 
allocate  storage  as  required  by  the  simulation  Drogram. 

The  area  of  interactive  orogramming  is  affected  by 
the  interactive  capabilities  of  the  programming  language. 
These  built  in  capabilities  are  the  base  level  for  the 
simulation.  Further  interactive  caoabilities  may  be 
provided  by  the  operating  system.  For  a  system  to  be 
genuinely  interactive*  it  is  necessary  for  the  system  to  be 
interruot  driven.  In  an  interrupt  driven  system/  the  user 
generates  an  interrupt  and  the  operating  system  then 
transfers  control  to  the  appropriate  interrupt  handler.  The 
instructions  in  this  interrupt  handler  dictate  the  resoonse 
to  the  interrupt.  Operating  systems  allow  the  user  to  write 
his  own  interrupt  handlers  to  either  suoplement  or  replace 
the  system  provided  handlers.  In  the  event  the  user  elects 
not  to  provide  his  own  handler/  the  operating  system 
provides  default  handlers.  8y  anticioating  the  required 
types  of  interrupts  and  the  aporopriate  responses/  the  user 
may  effectively  interruDt  the  execution/  create  a  display  or 
input  data/  and  return  to  the  point  of  interruption  and 
continue  execution. 

The  operating  system  aooroach  may  enhance  the  real 
time  caoability  of  the  simulation.  A  mu 1 t i process i na 
environment  allows  the  operating  system  to  oerform 
comDutation  on  one  process  while  simultaneously  performing 
i nput /output /  paging  or   some   other   operation   on   another 
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process.  This  means  the  programs  of  the  simulation  may 
fully  utilize  the  processors  of  the  computer  system  and  the 
processors  need  not  be  idle  while  a  single  program  switches 
from  one  processor  to  another  leaving  the  rest  of  the 
processors  idle  until  the  simulation  needs  its  services.  As 
a  worst  case*  the  ooerating  system  will  add  no  more 
execution  time  to  the  program.  The  operating  system  is 
needed  to  provide  user  interface  to  the  bare  machine  and 
hence  is  already  present  as  overhead  to  any  program  run  on 
t  he  mach  i  ne« 

The  post  analysis  report  writer  is  still  another 
program  to  exist  in  the  mu 1 t i orogramm i ng  environment.  The 
operating  system  keeps  the  segments  belonging  to  all 
simulation  programs  on  call  until  the  report  writer 
completes  its  usage  of  the  data.  Once  the  report  writer 
concludes  execution*  the  system  is  allowed  to  free  storage 
for  other  usaae. 

4.  Distributed  System 
The  envisioned  solution  would  have  two  central  processors. 
The  simulation  functions  will  reside  on  the  main  processor 
due  to  it's  computation  bound  c harac t er i st i cs ,  while  the 
graphics  and  inauiry  functions  will  reside  under  the  control 
of  another  possibly  smaller  processor. 

Since  the  main  CPU  is  charged  with  the  responsibility 
of  maintaining  the  master  data  base*  there  can  be  no  sharing 
of  data  items  between  processors.  The  graphics  processor 
must   receive   all  data  items  that  are    dynamically  changing. 
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It  must  also  interpret  all  user  commands  and  qenerate  a  CPU 
to  CPU  request  fo.r  the  data  items  necessary  to  fulfill  the 
user's  request.  Any  attempt  to  store  these  ever  changinq 
items  is  fruitless  and  will  result  in  either  duplicated 
files  or  excessive  data  transmission  between  the  two  CPUs. 
The  request  for  data  must  be  be  generated  on  an  interrupt 
basis  to  the  main  processor  so  that  the-  excessive  data 
transmission  and  data  redundancy  situations  do  not  occur. 

Dynamic  event  recordinq  must  be  accomplished  on  ooth 
processors  to  enable  system  to  be  restarted  at  any  specified 
state.  The  graphics  processor  will  be  required  to  store 
user  commands  and  decisions*  machine  state  and  perhaps 
display  generation  data.  The  main  CPU  will  be  tasked  with 
saving  its  machine  state  and  all  variable  values  for  the 
simulation  restart. 

Flexibility  of  the  system  now  spreads  over  the  two 
processors.  Not  only  must  the  imolementer  be  concerned  with 
the  mechanism  for  level  of  play*  level  of  display  and  size 
of  forces  represented  but  also  the  cor resoondi no  volume  of 
data  transmission  between  the  two  processors.  This  is  an 
added  concern  in  the  distributed  approach. 

Since  interactive  play  is  desired*  the  graphics 
processor  must  interpret  the  user's  commands  in  an 
interactive  role  and  also  generate  an  appropriate  interrupt 
to  the  main  processor  for  each  type  of  request.  This  will 
require  a  user  written  interrupt  handler  on  the  main 
processor   to   decipher   the   interrupt  and  process  it.   The 
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interrupt  handler  will  probably  not  be  on  the  operating 
system  level  and  thereby  will  cause  additional  delay  orior 
to  process  i  ng  it. 

The  idea  of  distributing  the  STAR  system  functions  to 
two  processors  was  conceived  to  solve  the  real-time 
requirement  problem.  Certainly  the  distributed  system  would 
run  closer  to  real-time  than  a  subroutine  call  system.  The 
required  CPU  to  CPU  communication  will  generate  some 
overhead  that  other  approaches  do  not.  The  user  must  see  the 
current  situation  status  displays  and  his  par t i c i Dat i on  must 
be  received  in  time  to  accurately  effect  the  outcome  of  the 
batt 1 e. 

The  problem  of  where  to  locate  the  report  writer  for 
post-execution  evaluation  arises.  It  should  be  capaole  of 
providing  the  user  with  his  reauirements  at  the  location 
generating  the  disdays.  This  means  that  the  main  processor 
must  either  continue  to  function  only  to  oass  data  to  the 
graphics  processor  for  this  ouroose  or  create  a  file  that  is 
readable  by  the  graphics  processor  during  this  phase.  Once 
again  additional  overhead  is  required  to  accomplish  both.  In 
the  first  case  additional  execution  time  is  required  by  the 
main  to  retriever  process  and  transmit  data  to  the  graphics 
processor.  In  the  latter  case  additional  time  is  required 
to  create  the  readable  file  should  the  two  processors  expect 
different  file  characteristics.  The  overhead  of  generating 
the  file  remains  in  either  case  and  under  all  concepts 
discussed,   however   such   record   and   file   attributes   as 
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header,  trailer*  inter-record  gaps*  blocki.nq  characteristics 
and  character  set  will  oresent  a  oroblem  should  two 
different  hardware  vendors  be  chosen  for  the  two  processors. 
Since  unchanging  data  items?  such  as  terrain  and  road 
networks*  exist  during  the  execution  of  any  given 
simulation*  they  are  stored  on  the  graphics  side  of  the 
system  originally  and  do  not  reguire  the  passing  of  large 
data  structures  as  that  of  terrain  representation.  This  is 
possible  due  to  the  use  of  parameterized  terrain  generation 
capability  of  the  simulation  to  produce  terrain  elevations 
at  any  given  point  on  the  battle  field. 

5.  Embedded  Graphics 

In  this  approach  the  simulation  program  is  the  center 
of  control  over  all  desired  functions.  The  basic  functions 
of  graphical  display*  inguiry  and  uDdate  are  fullfiled 
through  calls  to  aporopriate  subroutines. 

SIMSCRIPT  uses  a  basic  technique  of  executing  subroutine 
calls  from  the  timing-routine.  This  technique  selects  the 
next  event  to  transpire  from  the  event  list.  These  events 
were  previously  scheduled  by  other  subroutines  in  the 
simulation  (internal)  or  received  as  input  (external). 

The  sharing  of  information  between  the  three  basic 
functions  (simulation*  graphics  and  inquiry)  presents  no 
problem  because  the  reguired  common  data  can  be  stored  in 
global  variables  or  oassed  as  arquments  between  the  callinq 
and  called  subprograms.  Data  integrity  also  presents  no 
particular   problem   since   only   one   subprogram   may  be  in 
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execution  at  any  one  time  unless  some  type  of  parallel 
processor  is  utilized.  The  same  argument  applies  when  one 
subprogram  updates  a  variable  value  that  another  uses. 

The  recording  of  dynamic  events  can  be  easily 
accomplished  except  for  retention  of  the  machine  state. 
Since  machine  state  is  important  from  the  standpoint  of 
restarting  the  process  from  a  specified  state,  an  assembler 
level  subprogram  is  reauired  to  periodically  save  the 
necessary  information  on  some  secondary  storage  medium. 
Routines  will  also  have  to  be  developed  to  retain  the 
decisions  reached  and  periodic  simulation  stater  however 
these  can  be  written  in  the  basic  simulation  language  since 
all  reguired  information  is  defined  to  the  simulation 
program . 

Flexibility  of  the  system  for  level  of  play/  level  of 
display  and  size  of  forces  must  be  designed  into  the 
suborograms  but  may  be  realized  through  dynamic 
initialization  of  key  execution  parameters.  The  structure 
to  allow  this  must  be  incorporated  into  the  subprograms  so 
that  the  maximum  allowable  force  sizes  can  be  allowed. 

Interactive  play  can  be  achieved  through  careful  design 
and  implementation.  A  subDrogram  to  periodically  test 
display  terminals  for  user  participation  is  reouired.  This 
subprogram  will  interpret  the  user's  desired  functions  and 
schedule  the  compatadle  event  which  is  stored  in  the 
timing-routine  event  list  in  time  sequence.  These  events 
may  be  scheduled  NOW,  IN   10   MINUTES,   or   AT   ia30   HOURS, 
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however/  NOW  does  not  imply  instantaneous  execution  of  the 
function  since  other  oreviously  scheduled  events  for  the 
same  time  could  exist  with  a  higher  statically  defined 
priority. 

Maintaining  a  real-time  environment  is  not  hindered  by 
this  approach  when  considering  effect  on  the  outcome  of  the 
simulation/  however  this  apDroach  w^i  1  1  extend  the  execution 
time  reguired  for  the  battle.  Should  the  user  desire  to 
update  the  simulation  data  during  the  execution,  the 
simulation  process  is  halted  by  the  resident  operating 
system  until  control  is  returned.  The  user  need  only 
schedule  a  display  and  an  uodate  NOW  or  at  the  same  time 
with  the  display  event  having  the  next  highest  priori  tv  to 
the  update  event.  During  execution  the  display  will  be 
produced/  showing  the  current  simulation  status  and  then  the 
update  event  will  execute. 

The  reports-writer  enhancement  presents  some  difficulties 
particularly  during  post -s i mu 1  at i on  evaluation.  Since  the 
execution  of  the  simulation  has  been  terminated/  a  seoarate 
aoplication  orogram  is  reguired  to  process  the  saved  aata 
for  the  user. 

Although  the  subroutine  call  aporoach  is  the  simplest  to 
implement/  it  does  have  the  drawbacks  indicated.  This 
approach  will  have  several  beneficial  side-effects.  The 
graphic  diSDlay  is  scheduled  along  with  all  other  events  and 
is  placed  in  the  event  list  in  the  aporopriate  time 
sequence.  A  display  event  can  be  generated  with  the  SCHEDULE 
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A  GRAPHICS. DISPLAY  NOW,  SCHEDULE  A  GRAPHICS .DISPLAY  IN  10 
MINUTES  (DAYS  or  UNITS)  or  SCHEDULE  A  GRAPHICS .DISPLAY  AT 
1400  HOURS.  This  side-effect  qives  built-in  flexibility  to 
the  scheduling  of  a  display.  The  "GRAPHICS . D I  SPLAY "  event 
includes  initiation  of  inquiries  and  updates  to  the  data 
base  as  well.  Figure  3.5  depicts  samole  SIMSCRIPT  code  for 
this  type  of  subroutine  call. 
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PREAMBLE 


EVENT  NOTICES  INCLUDE  STOP .  SIMULATION 
EVERY  LOC. UPDATE  HAS  A  VEHICLE 
EVERY  LOS. UPDATE  HAS  A  WHEEL 
EVERY    DETECT    HAS    A     WHOLE 
DETECT. FOE. ENTIRE. TANK 
EVERY  TARGET. SELECT  HAS 
EVERY    FIRE    HAS    A 
CORE. POINTER. OR. TGT. ID 
EVERY   IMPACT    HAS    A 
BLOCK. POINTER. OR. TGT. ID 
EVERY   GRAPHICS. DISPLAY 
ADDRESS. OF. PARAMETER. LI  ST 


TANK     AND 


A  FIRING. TANK 
SHOOTING. TANK     AMD 

TANK. THAT. SHOT    AND 


HAS 


COMMAND. ID 


AND 


END 


MAIN 


CREATE  A  PARAMETER. LIST 

LET  ATTRIBUTE1 (PARAMETER. LIST)  =  valuel 
LET  ATTRIBUTE2(PARAM£TER.LIST)  =  valued 


SCHEDULE  A  GRAPHICS .DISPLAY  NOW 

LET  ADDRESS. OF. PARAMETER . LI  ST (GRAPHICS. DISPLAY) 
PARAMETER. LIST 


END 


EVENT  GRAPHICS. DISPLAY 


IF  COMMAND. ID(GRAPHICS. DISPLAY)  =  'I' 

PERFORM  INQUIRY  GIVEN 

ADDRESS. OF. PARAMETER. LIST (GRAPHICS. DISPLAY) 

IF  COMMAND. ID(GRAPHICS. DISPLAY)  =  'DT* 

PERFORM  TERRAIN. PLOT  GIVEN 

ADDRESS.OF.PARAMETER.LIST(GRAPHICS.DISPLAY) 


END 


FIGURE  3.5 
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F.  PREFERRED  SOLUTION 

In  the  selection  of  the  preferred  alternative/  those 
items  designated  as  common  considerations  play  an 
insignificant  role.  The  use  of  color  to  enhance  the  clarity 
of  the  displays  is  not  envisioned  to  introduce  an  additional 
burden  on  any  solution.  The  method  used  to  rapidly  Droduce 
a  contour  map  is  device  dependent  and  not  dependent  on  the 
preferred  solution.  Hard  copy  devices  depend  on  machine 
interfaces  and  are    therefore  implementation  independent. 

It  is  possible  for  all  alternative  solutions  to 
accomplish  the  sharina  of  date  files.  Database  management 
systems  are  designed  with  this  goal.  Dataoase  management 
systems  produce  a  data  independence  that  allows  each  user  to 
view  the  data  in  his  own  way.  Ooerating  systems  that 
support  segmentation  are  also  capable  of  supportina  the 
sharing  of  data.  The  operating  system  however  shares  the 
data  in  a  format  specific  manner.  The  distributed  accroach 
allows  sharing  of  data  files  between  the  central  processors 
through  the  use  of  a  distributed  ooerating  system  that 
allows  CPU  to  CPU  communication.  The  subroutine  call 
approach  uses  common  data  elements  through  parameter  oassinq 
techniques  and  global  variables. 

Dynamic  event  recording  is  the  first  area  in  which 
the  four  aporoaches  differ  significantly  in  their  ability  to 
perform.  All  approaches  are  capable  of  recording  decisions 
and  saving  the  values  of  variables  at  the  time  of  the 
decision.   It  is  not  a  normal  database   management   function 


68 


to  record  and  later  restore  the  state  of  the  machine 
registers.  This  interface  with  the  machine  must  be  made 
with  the  cooperation  of  the  operating  system.  The  operatinq 
system  approach,  on  the  other  hand,  has  the  interface  with 
the  machine  registers  as  part  of  its  normal  operations.  The 
distributed  aoproach  is  further  complicated  by  the  need  to 
save  the  state  of  multiple  CPU's  and  variable  values  in 
multiple  machine  memories.  The  subroutine  call  approach 
suffers  from  the  inability  to  directly  access  machine 
registers  in  much  the  same  manner  as  the  database  management 
system. 

Flexibility  in  the  level  of  display  and  the  level  of 
play  must  be  discussed  in  two  asDects.  Level  of  display  is 
a  function  of  the  level  of  play  in  the  fact  that  the  only 
possible  items  to  be  displayed  are  those  items  that  are 
stored.  The  routines  written  to  cause  the  display  will  be 
similar  for  all  approaches.  This  leaves  the  area  of 
flexibility  as  a  function  of  level  of  olay.  The  area  of 
flexibility  of  play  hinges  on  the  ability  to  generate  and 
store  the  appropriate  data  structure.  This  poses  a  problem 
to  the  database  management  system  approach  in  that  the 
system  must  dynamically  generate  the  data  structure  at 
execution  time.  The  generation  of  the  maximum  size  data 
structure  at  every  execution  of  the  simulation  would  be 
wasteful  of  storage.  The  operating  system  approach  is  not 
hindered  Dy  the  flexibility  constraint.  The  operating 
system   will   automatically   reserve   storaae   for   the  data 


69 


structure  specified  bv  the  simulation  program.  The 
distributed  aporoach  is  similar  to  the  operating  system 
approach  in  that  the  operating  system  of  the  distributed 
system  will  allocate  storage  as  required  by  the 
corresponding  programs.  The  subroutine  call  aoproach  is 
unaffected  by  the  flexibility  of  play.  By  changina  incut 
parameters;  the  user  may  dictate  the  size  and  structure  of 
the  units  part i c i Dat i ng  in  the  simulation. 

Interactive  orogramminq  for  the  database  management 
alternative  is  broken  into  two  areas.  The  inguiry  mode  of 
the  database  system  is  limited  only  by  the  dataoase 
designer.  When  the  user  asks  and  what  he  is  allowed  to  ask 
are  design  considerations.  All  interactive  capabilities 
other  than  the  inquiries  are  limited  by  the  Drogramming 
language  concerned.  The  subroutine  call  approach  is  also 
limited  by  programming  lanauages.  The  operating  system 
aoproach  is  capable  of  fully  interrupt  driven  processing. 
The  ability  to  interact  is  enhanced  by  the  users  ability  to 
write  interrupt  handlers  to  respond  to  user  qenerated 
interruots.  The  distributed  system's  user  programs  are  also 
limited  by  the  chosen  programming  language. 

Real-time  processing  is  hindered  by  the  database 
management  alternative.  The  system  must  translate  all  data 
references  into  the  appropriate  addresses  in  order  to 
complete  the  data  references.  The  operating  system  approach 
does  not  affect  the  real-time  ability  of  the  simulation. 
The   distributed   system  will  slow  the  simulation  due  to  the 
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time  required  for  CPU  to  CPU  communication.  The  greatest 
slow  down  will  be  for  the  subroutine  call  alternative  since 
all  processing  must  stop  in  the  simulation  while  the 
subroutine  creates  the  display  data. 

From  the  above  discussion  the  operating  system 
aoproach  is  the  only  alternative  that  satisfies  all  the 
requirements  for  the  system.  There  are  several  other 
considerations  that  favor  the  operating  system  approach.  In 
the  ooerating  system  aporoach  the  key  is  the  sharing  of 
data.  The  key  data  to  be  shared  is  generated  bv  the 
existina  simulation  program.  Further  oroqram  development  to 
share  this  existing  data  may  be  done  independently  without 
adversely  affecting  the  existing  program. 

Another  consideration  is  the  availability  of  a  system 
to  support  the  simulation.  Both  the  database  management 
system  and  the  operating  system  approaches  deoend  upon  a 
complicated  programming  effort.  A  tailored  database 
management  system  would  have  to  be  written  and  at  best  be  an 
experimental  system  with  unknown  efficiency.  On  the  other 
hand,  general  ouroose  ooerating  systems  capable  of 
supporting  this  simulation  system  have  been  written  and 
tested.   These  proven  systems  are  available  today. 

It  is  anticioated  that  the  simulation  wil  be  run  with 
classified  inout  data.  All  solutions  to  the  problem,  except 
the  operating  system  approach,  delegate  the  problem  of 
security  to  an  external  mechanism.  Some  operating  systems 
are    capable  of  providing  security  for   the   classified   data 
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without  depending  on  an  external  mechanism. 

The  last  consideration  is  the  complexity  of  the 
solution.  The  operating  system  approach  places  the  entire 
burden  on  the  operating  system  to  perform  tasks  beyond  the 
capability  of  the  programming  languaae.  The  database 
management  system  reguires  a  complicated  relationship 
between  the  database  system  and  the  operating  system  since 
the  database  management  svstem  is  unable  to  fulfill  all  the 
requirements.  The  operating  system  is  the  only  alternative 
to  perform  all  requirements  in  a  stand-alone  basis. 
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-IV.  SOLUTION  ANALYSIS 
System  analysis  examines  the  existing  and  proposed 
software  and  produces  the  logical  design  for  the  system.  It 
is  in  this  phase  that  the  inter-relationships  between 
modules  are  examined  *  including  determination  of  both 
coordination  and  synchronization  of  modules.  The  proposed 
simulation  system  is  composed  of  four  programs  existing  in  a 
mutually  cooperating  environment.  The  first  and  most 
important  of  these  four  proarams  is  the  monitor  program 
which  is  the  master  program  that  coordinates  the  use  of  the 
system  and  is  capable  of  initiating  anv  of  the  capabilities 
of  the  system.  A  second  program  is  the  simulation  Drogram 
itself.  This  Drogram  is  the  current  version  of  STAR.  The 
third  program  is  a  graphics  program  that  produces  all  maps 
ana  overlays  to  the  maps.  The  last  program  contains  all 
administrative  routines  such  as  report  writers/  inquiry 
operations*  all  tutorials  and  assistance  functions.  The 
operating  system  coordinates  these  programs  and  converts 
isolated  programs  into  the  simulation  system  described  in 
Chapter  I I . 


A.  OPERATING  SYSTEM  REQUIREMENTS 

In  order  for  an  ooerating  system  to  properly  implement 
the  simulation  system*  it  must  have  a  number  of  control 
features.  These  required  features  fall  into  the  four 
functional    areas   of   segmented   memory/   multiprocessing* 
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synchronization  of  processes  and  segment  isolation. 
1.  Segmented  Memory 

The  sharing  of  data  between  user  programs  is  reguired 
to  implement  the  STAR  model.  The  simulation  generates  a 
data  file  that  is  displayed  by  the  various  graohics 
routines.  This  data  file  is  accessed  by  the  routines  that 
display  dynamic  movement,  animate  .weapon  firing,  display 
impact  of  rounds,  and  display  unit  positions  as  well  as 
detected  enemy  positions.  This  data  must  not  only  be 
accessed  but  also  be  updated  by  the  routines  that  enable 
dynamic  route  and  position  selection  and  support  the  inguiry 
functions.  An  operating  system  capable  of  segmented  memory 
allows  this  sharing  to  take  place  [Daley  and  Dennis  19681. 

A  segment  is  a  collection  of  information  that  is 
important  enouah  to  be  given  a  name.  A  segment  is  the  basic 
unit  of  sharing.  Associated  with  a  segment  is  a  collection 
of  attributes*  including  a  unigue  identifier  and  an  Access 
Control  List.  The  Access  Control  List  maintains  information 
specifying  the  processes  that  may  access  that  segment  and 
whether  the  authorized  access  includes  any  combination  of 
read,  write  or  execute  permission.  Each  segment  may 
consists  of  up  to  six  major  parts.  The  text  section 
contains  the  pure  unmodified  parts  of  the  object  code  which 
would  contain  the  program  constants  as  specified  in  the 
SUBSCRIPT  PREAMBLE.  The  definition  section  contains 
nonexecutable  information  used  by  system  programmers  in 
debugging   and   by   the  operating  system  in  dynamic  linking. 
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The  linkage  section  contains  the  impure?  modifiable  parts  of 
the  object  code  and  may  be  made  ud  of  two  types  of  data. 
The  links  used  to  establish  addresses  at  run  time  are  the 
first  tyoe  of  entry  and  since  the  memory  is  demand  paged* 
these  addresses  may  change.  The  second  type  of  data  is  the 
data  items  from  the  program  that  will  be  modified  during 
execution.  All  variables  will  bestored  here.  The  static 
section  may  also  be  used  for  storaae  on  a  oer  process  basis 
alternately  this  storage  may  be  included  in  the  linkage 
section.  A  break  map  section  contains  information  used  by 
debuggers.  The  last  section,  the  symbol  section/  contains 
anything  generated  that  is  not  stored  elsewhere  [Honeywell 
1975]  . 

All  segments  that  are  competina  for  system  resources 
are  listed  in  a  system-wide  Active  Segment  Table.  This 
table  allows  the  ooerating  system  to  know  which  segments  are 
currently  active  and  where  they  are  located  in  memory. 
Table  length  is  finite  which  reguires  the  operating  system 
to  limit  the  number  of  segments  capable  of  competing  for 
system  resources.  This  limiting  of  processes  reduces  the 
amount  of  time  lost  due  to  the  switching  of  processors  from 
one  process  to  another. 
2,    Process  States 

A  orocess  is  a  set  of  related  procedures  and  data 
undergoing  execution  and  manipulation.  Processes  will 
generally  contain  one  or  more  procedure  segments*  one  or 
more   data   segments*   a  stack  segment  and  a  linkage  seament 


75 


for  each  procedure  segment  included  in  the  process. 
Processes  within  a  computer  fall  into  one  of  three  execution 
states.  A  process  is  said  to  be  running  if  it  is  currently 
executing  on  a  processor.  A  process  is  ready  if  it  would  be 
running  should  a  processor  be  available.  A  process  is 
waiting  if  it  cannot  make  immediate  use  of  a  processor  since 
it  is  waiting  for  some  external  ("to  the  process)  event.  The 
operating  system  keeps  track  of  these  processes  in  the 
system-wide  Active  Process  Table.  These  three  types  of 
processes  in  the  Active  Process  Table  require  synchronized 
use  of  shared  segments. 

3.  Synchronization  of  Processes 

In  order  to  synchronize  processes  some  method  of 
communication  between  the  processes  must  exist.  This 
interprocess  communication  is  monitored  by  a  mechanism  known 
as  the  traffic  controller  which  functions  as  a  general 
purpose  supervisor  for  control  of  parallel  operations  (Daley 
ana  Dennis  1968].  Two  of  the  more  interesting  mechanisms 
provided  by  the  traffic  controller  are  the  block  and  wakeup 
functions.  The  block  function  forces  a  process  to  wait  for 
an  occurrence  of  an  event  generated  by  some  other  process 
while  the  wakeup  function  allows  the  process  to  be  notified 
that  the  event  has  occurred  and  processing  may  resume.  This 
blocking  of  a  process  is  recorded  in  the  Active  Process 
Tabl e. 

Another  mechanism  used  in  synchronization  is  a 
condition  handler.   Users  and  processes  may  communicate  with 
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processes  through  the  use  of  condition  handlers.  Condition 
handling  refers  to  an  activity  resulting  from  a  hardware  or 
software  condition  named  by  the  user's  program.  The  user 
may  implicitly  or  explicitly  identify  the  code  to  be 
executed  in  resoonse  to  the  condition.  To  initiate  user 
interaction  with  the  simulation,  the  programmer  specifies 
the  pressing  of  the  ATTN  key  on  the  terminal  keyboard  as  a 
hardware  condition.  In  response  to  this  condition* 
execution  control  is  transferred  to  a  condition  handler 
which  contains  code  to  request  the  tyDe  of  action  required 
by  the  user.  The  user  oerforms  his  desired  interaction  and 
the  simulation  resumes  execution.  Condition  handling  need 
not  be  a  riaid  response  to  the  specified  condition.  The 
programmer  has  the  option  to  specify  condition  handlers  on  a 
segment  by  segment  basis  since  condition  handlers  are  pushed 
onto  a  stack  as  thev  are  defined  and  cooped  from  the  stack 
when  the  oroc ed ure  seqment  for  which  they  are  defined  is 
exited.  In  this  manner,  the  programmer  may  SDecify  a  global 
condition  handler  as  the  general  resoonse  to  a  given 
condition  and  redefine  the  response  to  the  condition  on  a 
procedure  by  procedure  basis  should  the  response  change  for 
each  particular  environment.  Should  the  response  to  the 
condition  be  the  activation  of  another  orocedure,  the 
condition  handler  then  becomes  another  of  the  deliberately 
cooperating  procedures. 

Deliberately  coooerating  programs  or   procedures   may 
interact  through  the  use  of  interrupts  which  are  synchronous 
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events  internal  to  the  machine.  When  one  procedure  desires 
to  call  another  procedure*  the  callinq  procedure  generates 
an  interrupt.  The  key  to  flexibility  in  interrupt  handling 
is  to  convert  this  interrupt  to  a  wakeup.  The  interrupt  is 
sent  to  the  interprocess  communication  controller  which  in 
turn  sends  a  wakeup  to  the  called  procedure.  This  called 
procedure  is  then  activated  and  execution  may  resume.  There 
is  no  problem  with  simultaneous  use  of  a  procedure  by 
multiple  calling  procedures  since  all  references  to  the 
called  procedure  are  made  via  the  calling  procedure's 
linkage  segment.  Once  the  called  proceoure  has  completed 
execution,  the  called  procedure  places  itself  in  a  blocked 
status  to  await  further  use  [Graham  and  Denning  1972]. 

Coordinated  sharing  of  writable  data  segments  may  be 
handleo  through  a  lock  mechanism  provided  by  the  operating 
system.  This  lock  mechanism  is  applied  to  a  data  segment 
whenever  that  segment  is  being  utilized  by  a  process  capable 
of  modifying  its  contents.  Further  attempts  to  reference  a 
locked  segment  will  be  denied  until  the  segment  is  unlocked. 
The  lock  mechanism  blocks  the  process  that  is  attempting  to 
use  data  segment  and  maintains  the  identification  of  the 
requesting  process  in  a  list  structure.  Once  the  segment 
has  been  updated/  the  locking  mechanism  sends  a  wakeup  to 
the  next  process  selected  to  use  the  data,  unlocking  the 
data  segment  for  that  process.  This  procedure  is  repeated 
until  all  requests  are  fulfilled  and  the  data  segment  is 
unlocked  to  await  future  use. 
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4.  Isolation  Techniques 

Interprocess  isolation  is  accomplished  through  the 
Access  Control  List  discussed  in  section  A-l  of  this 
Chapter.  Intraorocess  isolation  is  implemented  through  the 
use  of  concentric  protection  rings  where  a  ring  bracket  is 
associated  with  each  segment.  The  ring  bracket  is  an 
ordered  triple  <R1/R2/R3>  which  sbecifies  the  access  bracket 
<R1,R2>  and  the  call  bracket  <R2/R3>.  These  two  subsets  of 
the  ring  bracket  dictate  the  read*  write/  execute  and  call 
access  for  that  segment,  A  procedure  may  execute  in  any 
ring  from  Rl  to  R2  inclusive  and  may  be  called  by  any 
procedure  in  rings  (R2  t  1)  to  R3  inclusive/  orovided  the 
calling  procedure  has  sufficient  security  clearance.  A  data 
segment  commonly  has  R2  eaual  to  R3  since  calling  a  data 
segment  has  no  meaning.  A  procedure  segment  may  write  to  a 
data  seament  in  rings  0  to  Rl  inclusive  and  read  from  a  aata 
segment  residing  in  the  region  0  to  R2  inclusive.  Again/ 
read  and  write  access  are  denied  to  any  segment  in  any  ring 
that  does  not  have  sufficient  access  qranted  in  the  Access 
Cont  rol  List. 

A  segment  may  also  have  a  security  level  associated 
with  it.  This  security  level  is  composed  of  two  parts/ 
security  classification  and  security  category  [Schiller 
1975],  The  security  classification  is  a  tvpe  of 
compart  men t a  1  i zat i on  similar  to  the  Department  of  Defense 
security  classifications  secret/  confidential/  etc.  This 
security  classification   is   a   totally   ordered   set   where 
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secret   is   strictly  greater  than  confidential  and  so  forth. 

The  second  part   of  the   security   level   is   the   security 

category   whicn  is  a  modifier  to  the  security  classification 

and  analogis  to  the  Department   of   Defense   categories   of 

crypto/   NATO,   etc.  In   addition  to  access  granted  by  the 
Access   Control   List/   procedures    must    also    have    an 

appropriate  security  level  in  order/  to  gain  access. 


B.  ANALYSIS  OF  ENHANCEMENTS. 

Certain  design  characteristics  must  be  followed  in  the 
design  of  all  software  for  the  proposed  system.  All 
software  developed  should  be  easily  portable/  avoiding 
locally  oroduced  library  functions  since  they  may  not  exist 
at  another  installation.  All  modules  should  be  human 
engineered  to  permit  easy  use.  Operator  inputs  should  be 
minimal  and  concise  with  default  values  provided  for  all 
modes/  parameters  and  variables.  These  defaults  lessen  the 
burden  on  the  user  and  facilitate  the  reguirement  for 
minimal  input.  Additionally/  defaults  reduce  the  number  of 
user  errors.  Maintenance  responsibility  for  the  software 
must  be  charged  to  a  specified  individual  or  group  of 
knowledgeable  individuals.  All  graohics  routines  developed 
should  comply  with  the  new  graphics  standards  under 
development  by  the  American  National  Standards  Institute 
[Newman  and  van  Dam  1978]  . 

In  addition  to  the  existing  simulation  program,  several 
new  modules  and  separate  programs  must  be  written  to  achieve 
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the  type  of  interactive  simulation  described  in  Chapter  II. 
These  additional  modules  and  programs  include  all  graphical 
displays*  inquiry,  synchronization  and  report  qenerator 
f unct  i  ons • 

The  choice  of  utilizing  the  operating  system  approach  to 
implement  the  simulation  system  has  facilitated  the 
programming  effort  required.  The  area  of  flexibility  of 
play  no  longer  concerns  the  proqrammer.  Storage  for 
variables  is  automatically  allocated  as  a  normal  function  of 
the  operating  system.  The  programmer  does  not  need  to 
concern  himself  with  an  elaborate  data  structure  that  is 
capable  of  growth  since  this  burden  is  assumed  bv  the 
ooerating  system.  Flexibility  of  display  becomes  a  oroblem 
of  searching  for  all  the  elements  of  the  unit  being 
displayed  and  then  using  some  aoprooriate  weighting  factor 
to  properly  position  the  unit  symbol. 

Programs  may  be  developed  independently  of  the 
simulation  by  using  simulated  data  files  and  therefore  not 
hinder  the  use  of  the  simulation  or  reguire  duplicate  copies 
of  the  simulation  program  for  developmental  purposes.  When 
the  additional  programs  are  tested  and  pronounced  ready  for 
use;  the  only  action  reauired  is  to  inform  the  operating 
system  to  allow  access  to  the  shared  data  files. 
Synchronization  of  use  of  these  shared  files  is  reguired  but 
mechanisms  discussed  in  section  A-3  of  this  chapter  allow 
this  synchronization  to  occur. 

1.  Interactive  Programming 
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The  area  of  interactive  programming  may  be  broken 
into  two  sections.  The  user  may  interact  with  the  simulation 
program  as  well  as  the  individual  simulation  programs 
interacting  with  each  other.  The  case  of  the  user 
interacting  with  the  simulation  may  be  satisfied  by  the  use 
of  condition  handlers  while  individual  programs  cooperating 
with  one  another  may  be  accomplished  through  the  use  of 
interrupt  handlers. 

An  example  of  condition  handling  may  be  the 
implementation  of  dynamic  route  selection.  When  the  light 
pen  is  activated*  a  hardware  condition  occurs  and  execution 
control  is  transferred  to  the  condition  handler.  The 
condition  handler  sends  a  wakeuo  to  an  updating  procedure. 
This  uodating  procedure  accesses  the  data  and  places  a  lock 
on  the  data  segment.  This  lock  prohibits  the  use  of  the 
data  while  it  is  being  updated.  when  uDdating  is  completed, 
the  lock  is  removed*  the  update  procedure  places  itself  in  a 
blocked  status  to  await  its  next  wakeup  message*  the 
condition  handler  is  exited  and  execution  resumes. 

Use  of  coordination  by  interruDt  handling  may  be  seen 
in  the  dynamic  updating  of  positions.  When  the  movement 
moaule  changes  the  location  of  the  unit*  an  interrupt  is 
generated  as  the  movement  module  is  exited".  This  interrupt 
is  converted  into  a  wakeuo  that  is  sent  to  the  display 
routine.  The  display  routine  creates  the  new  display  and 
then  Dlaces  itself  in  blocked  status  to  await  the  next 
position   change.    This  conversion  of  interrupts  to  wakeups 
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not  only  facititates  display  but  also  allows  the  procedure 
to  be  active  only-  as  required.  Extraneous  nonexecuting 
simulation  routines  need  not  be  in  primary  storage  until 
required  for  use  and  display  routines  need  not  continuously 
draw  the  same  picture  in  order  to  prevent  missing  an  event. 
Displays  may  now  be  made  only  as  change  occurs. 
2. Real-time  , 

Real-time  must  be  approached  from  both  the  computer 
science  and  modeling  definitions.  The  computer  science  real 
time  is  accomplished  by  the  synchronization  mechanisms 
discussed  in  section  A-3.  The  various  programs  and 
procedures  are  forced  to  run  in-steo  since  they  are  called 
by  wakeups  from  the  main  simulation  on  an  as  required  basis. 
T'h  i  s  system  will  have  least  overall  detriment  to  the 
simulation  in  the  model ina  real-time  sense.  Memory 
management  may  prove  to  slow  the  simulation  from  paging 
activities  but  proper  selection  of  the  program's  workinq  set 
size  will  reduce  these  oaqing  delays  to  a  minimum  [Denning 
1968],  A  clever  operating  system  will  have  facitities  for 
maintaining  the  current  working  set  size  as  a  program 
executes.  Associative  and  cache  memories  will  also  speed  uo 
execution  of  the  simulation  execution  due  to  high  speed 
address  translation  and  reference  tSchroeder  19711.  The 
mechanisms  to  synchronize  segment  usage  may  cause  some 
slowing  while  procedures  are  in  a  blocked  status.  This 
slowdown  will  be  overcome  since  separate  programs  will  be 
allowed   to  execute  simultaneously  in  a  multiprogramming  and 
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multiprocessing  environment.  An  example  of  synchronization 
of  segment  usage  is  the  calculating  line  of  sight  while  the 
display  of  current  positions  is  being  oroduced  by  another 
processor. 

3.  Von  i  tor  Program 

The  monitor  program  provides  a  master  control 
facility  for  the  modeler.  This  monitor  program  provides  the 
main  condition  handler  for  the  simulation.  From  the  master 
console*  any  capability  of  the  simulation  system  may  be 
called  at  any  time.  Any  privileged  instructions  available 
to  the  modeler  but  not  the  war  gamer  will  be  executable  from 
this  terminal. 

The  monitor  program  will  be  written  as  a  separate 
program  executing  on  a  dedicated  display  device.  All 
modules  of  the  monitor  program  will  be  of  sufficient 
priority  to  preemot  any  of  the  executing  routines  of  the 
other  programs,,  of  the  system. 

The  monitor  program  is  made  possible  through  the  use 
of  condition  handlers  and  shared  data.  The  monitor  program 
will  also  be  capable  of  placing  locks  on  data  files  since  it 
is  capable  of  writing  to  data  files.  Coordination  with  the 
remaining  procedures  will  be  accomplished  through  the  block 
and  wakeup  mechanisms.  The  access  rights  and  security 
levels  of  all  Drocedures  will  be  set  by  the  monitor  program. 

4.  Dynamic  Event  Recording 

Dynamic  event  recording  is  used  to  save  the  execution 
state   of   the  simulation  at  various  decision  making  points. 
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This  state  of  execution  is  composed  of  two  distinct  parts 
with  distinct  characteristics.  The  state  of  the  simulation 
is  the  set  of  values  of  all  simulation  variables.  Whenever 
a  decision  is  input/  the  operating  system  needs  to  copy  the 
data  segments  containing  the  appropriate  variable  values 
onto  a  secondary  storage  device.  These  values  must  be 
copied  prior  to  any  changes  due  to  the  input  decision.  The 
state  of  the  machine  is  characterized  by  the  values  in  the 
machine's  internal  registers.  At  the  decision  point/  the 
operating  system  saves  the  register  values  in  secondary 
storage.  The  operating  system  must  then  label  these  values 
and  inform  the  user  of  the  assiqned  label  and  resume 
execution.  At  some  future  time  when  the  user  desires  to 
return  to  this  point/  he  need  only  supply  the  label  value  of 
the  decision  point  and  the  operating  system  will  then 
restore  the  simulation  and  execution  states/  returninq 
control  to  the  user  for  his  new  decision. 
5 .  Report  Wr  i  t er 

The  purpose  of  the  report  writer  is  to  produce 
statistical  reports  based  on  stored  historical  data  and 
current  oattle  status.  It  should  have  the  capability  to 
produce  graph  summaries  of  the  user's  desired  format.  For 
instance/  bar  graphs  may  be  desired  over  simple  plots  for 
certain  items.  For  ease  of  implementation/  this  should  be 
defineo  as  a  user  requirement  however  the  report  writer  can 
be  developed  with  sufficient  flexibility  to  allow 
interactive  user  format  selection  at  the  exoense   of   laraer 
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programs-  If  sufficient  storage  space  (memory  or  secondary) 
exists  and  system  execution  is  not  sufficently  degraded, 
then  this  flexibility  should  be  pursued  for  the  benefit  of 
the  ul  t  i  mate  user . 

The  reDort  writer  is  a  procedure  included  in  the 
administrative  routines  program.  Prooer  selection  of  ring 
brackets  and  delegation  of  access  oermi ss i on  will  allow  the 
report  writer  to  reference  data  and  perform  its  required 
function.  The  report  writer  may  be  invoked  from  either  the 
administrative  program  or  the  monitor  program.  The  invoking 
program  sends  a  wakeup  to  the  report  writer  to  initiate  the 
procedure.  Upon  completion,  the  report  writer  places  itself 
in  a  blocked  status  to  await  further  use. 
6.  Ingui  ry  Mode 

The  function  of  the  inguiry  mode  is  to  allow 
commanders  and  their  staff  sections  to  auestion  the 
simulation.  Legitimate  inquiries  are  those  that  each  agency 
would  normally  initiate  during  an  actual  battle.  For 
instance  the  S-l  would  not  be  allowed  to  query  directly  the 
status  of  some  area  outside  his  cognizance  but  rather 
require  him  to  communicate  via  the  appropriate  agency  which 
has  cognizance  over  the  area  in  question.  Chapter  II, 
section  0  previously  identified  normal  areas  of  cognizance 
for  the  staff  sections. 

Answers  to  any  agency's  request  must  reflect  the 
accuracy  and  timeliness  exDerienced  in  a  true  battle.  This 
requirement  should  be  handled  in  the   simulation   of   inter- 
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organizational    communication    oaths.    Any   accurate   and 
instantaneous  reply  could  be  misleading  to  to  the  commander. 
Human   factors   must   be  considered  and  accounted  for  in  the 
inquiry  mode's  operation  to  reflect  realism. 
7.  Map  and  Overlay  Generation 

Initial  terrain  generation  experiments  were  conducted 
on  a  POP  11/50  using  a  TEK  TRONIC'S^  40  1  4-1  display  device  as 
the  display  medium.  The  4014  has  several  disDlay  modes 
including  point  and  vector.  A  resulting  tutorial  was 
developed  for  use  and  is  included  as  APPENDIX  A. 

Current  methods  used  for  generating  contour  maps  from 
stored  matrices  of  data  could  not  be  usea  to  display  the 
terrain  for  this  simulation  CDayhoff  19631.  One  of  the 
advantages  of  parametric  terrain  is  that  terrain  may  be 
calculated  rather  than  stored  allowina  large  areas  to  be 
modeled.  Using  calculated  terrain*  the  only  altitude  known 
is  that  of  the^current  location.  The  decision  was  made  to 
scan  the  area  from  South  to  North  and  from  West  to  East  to 
determine  the  location  of  contour  lines.  The  resulting 
problem  was  that  with  a  constant  samoling  step  size*  it 
could  not  be  guaranteed  that  the  step  taken  would  in  fact 
fall  on  a  contour  line.  Next  a  ooint  was  accepted  as  being 
on  a  given  contour  line  if  it  were  within  a  specified 
tolerance  from  the  contour  line.  This  tolerance  was 
measured  in  the  vertical  direction.  The  first  attempt  at 
displaying  parametric  terrain  utilized  the  point  mode  of  the 
4014.    The   deficiency   noted   in   this   approach   was   the 


87  ' 


inability  to  establish  contour  lines  since  the  display  image 
consisted  of  a  serfes  of  dots.  To  accomplish  the  illusion  of 
lines  a  sufficiently  small  delta  x  and  delta  y  had  to  be 
used  thus  extending  execution  time  for  anv  given  piece  of 
terrain.  If  the  display  was^to  be  magnified  to  any  degree 
the  line  illusion  became  visible  dots  or  points  once  again. 
This  effect  demonstrated  the  need  to  draw  contour  lines 
using  the  vector  mode  of  the  4014. 

In  order  to  utilize  the  vector  mode*  a  drawing 
algorithm  was  developed.  The  algorithm  used  to  determine 
the  direction  of  draw  was  guite  simple.  Once  a  decision  to 
draw  was  made/  all  points  adjacent  to  the  current  point  in  a 
North  or  East  direction  were  calculated  and  the  line  was 
drawn  to  the  point  closest  to  the  contour  elevation.  This 
approach  produced  contour  bands  rather  than  contour  lines. 
These  bands  were  acceptable  on  steep  slopes  but  in  the 
flatter  areas  ..they  were  guite  wide.  An  attempt  to  reduce 
the  number  of  line  segments  to  be  drawn  was  made  by  drawing 
to  a  given  point  only  if  the  ooint  immediately  North  of  it 
was  farther  from  the  contour  line  than  the  current  point. 
This  produced  contour  lines  that  were  shaded  on  the  North 
side.  The  solution  to  this  problem  resulted  in  an 
additional  condition  that  a  point  would  not  be  considered 
for  plotting  unless  it  were  closer  to  the  contour  line  than 
both  the  adjacent  points  in  the  North  and  South  directions. 
The  resulting  map  was  adeguate  but  still  retained  shading 
along  a  hill's  major  access  in  the  area    of  the  contour   line 
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plus  and  minus  the  tolerance.  The  shading  was  negligible 
near  the  Deak  of  the  hill,  but  quite  distracting  near  the 
base.  The  shape  given  by  the  distribution  is  increasingly 
flatter  as  one  proceeds  outward  from  the  center  of  the  hill. 
The  solution  to  this  problem  was  in  the  calculation  of  a 
dynamic  tolerance.  This  tolerance  was  calculated  by 
determining  the  distance  from  hill  center  that  the 
distribution  reached  three  standard  deviations  or  fell  below 
some  specified  minimum  altitude*  whichever  comes  first. 
This  method  oroduces  an  acceDtable  mao.  The  resulting 
a  1 gor  i  t  hm  foil ows : 

1.  Locate  point  closest  to  contour  line. 

2.  Sample  adjacent  ooints  to  North  and/or  East. 

3.  Draw  line  to  adjacent  ooint  closest  to   contour 
line. 

4 .  Locate  next  coint  closest  to  next  contour  line. 

The  major  drawback  to  this  approach  lies  in 
consumption  of  time.  This  method  is  of  complexity  of  order 
N  squared  meaning  that  doubling  the  size  of  the  mao  to  be 
displayed  roughly  quadruples  the  execution  time.  This 
routine  is  by  no  means  real-time  in  nature.  Experiments 
were  conducted  to  speed  up  the  drawing  of  this  contour  map. 
The  map  may  be  drawn  in  real-time  if  the  calculations  are 
not  required  every  time  the  terrain  is  displayed.  The 
solution  requires  that  the  commands  to  move  and  draw  that 
are  generated  by  the  CPU  and  sent  to  the  display  device  must 
De  intercepted  and  written  to  a  data  file.  Uoon  a  request 
to  draw  a  given  area*  only  the  actual  move  and  draw  commands 
need  be  executed.   These  commands  may  be  created  and   stored 
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as   the   terrain  is  designed  and  referenced  later  during  the 
simulation  as  required. 

The  ability  to  draw  different  sections  of  the 
battlefield  is  easily  attained.  By  using  a  device  such  as 
the  TEKTRONIX  4014  a  virtual  window  may  be  defined  to  the 
display.  This  virtual  window  is  mapped  onto  the  physical 
display  window  and  only  the  points  within  the  virtual  window 
are  displayed.  This  virtual  window  may  be  dynamically 
created  from  inout  parameters  from  the  console.  The  contour 
lines  may  be  stored  in  separate  files  per  individual  line 
elevation  thus  allowing  combinations  to  be  plotted  and 
giving  flexibility  of  selection  of  line  interval. 

Overlays  will  be  plotted  on  the  basic  contour  map. 
These  overlays  may  be  selected  individually  or  in  any 
combination  of  the  available  overlays.  The  use  of  color 
diSDlays  will  make  the  overlays  stand  out  from  the  map  and 
avoid  confusion  when  multiple  overlays  are  requested.  In 
oraer  to  avoid  destruction  of  the  contour  map  by  overwriting 
from  the  overlays*  the  display  terminal  must  have  a 
selective  erase  capability.  This  will  allow  the  removal  of 
a  specific  overlay  without  disturbing  any  others  that  may  be 
displayed  at  the  time  of  removal. 
8.  Security  of  Classified  Data 

Physical  security  of  the  classified  data  during  input 
or  output  remains  the  problem  of  the  user.  The  terminals 
used  must  be  in  a  secure  environment  to  avoid  compromise 
before   data   is   entered   into   the   computer  and  after  the 
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classified  outDut  is  generated.  Remote  use  of  the 
simulation  will  be  possible  if  scrambling  devices  are  placed 
on  the  communication  lines.  Computational  security  is 
provided  by  the  operating  system  since  properly  specifying 
the  security  level  of  the  simulation  will  cause  the  internal 
protection  mechanisms  to  safeguard  the  data  from  tampering 
within  the  computer.  Thus  the  simulation  running  classified 
data  may  be  described  with  a  security  level  of 
<c 1 earancer ST AR>  and  thereby  refuse  usage  of  the  data  to 
anyone  regardless  of  classification  without  STAR  access. 
9.  Library  Routines/Tutorials  Needed 

In  any  interactive  system  certain  library  routines 
and  tutorials  make  the  system  more  convenient  to  use.  These 
routines  lie  resident  within  the  system  and  are  capable  of 
being  called  by  the  user.  Several  readily  identifiable 
examples  are  discussed  in  the  following  sections. 
a.  Terrain  Generation  Package 

The  purpose  of  the  terrain  generation  package  is 
to  allow  the  user  to  define  any  given  terrain  area  in  terms 
of  the  reauired  parameters  prior  to  the  execution  of  the 
battle  simulation.  The  terrain  generation  package  uses  the 
identical  data  items  reguired  by  the  elevation  routine  of 
the  simulation.  Once  the  user  has  defined  the  terrain  to 
his  satisfaction  he  can  elect  to  creat  a  file  containina  the 
display  device  commands  generated  during  the  display  phase. 

The  terrain  generation  package  includes  two  major 
items*    a    highly    interactive   program   and   a   tutorial 
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describing  the  program's  use.  The  interactive  program 
allows  the  user  to  define  ana  display  the  terrain  of  the 
battle  area.  The  definition  phase  includes  capabilities  to 
build*  modify*  add-to  or  delete-from  a  data  file  containing 
the  parameters.  Appendex  A  defines  these  allowable 
f unct  i  ons . 

The  terrain  display  phase  allows  the  user  to  draw 
contour  lines  of  his  chosen  level  from  the  data.  The  user 
specifies  Pounds  for  the  display  in  terms  of  maximum  and 
minimum  grid  coordinates*  the  contour  level  and  the  step- 
size  desired.  The  user  specified  bounds  give  the  illusion 
of  zooming-in  or  away  from  the  terrain.  Bounds  smaller  than 
the  defined  battle  area  will  cause  a  smaller  area  to  be 
displayed  in  the  static  display  window  creating  a  blown-up 
or  zoom-in  effect.  Conversely*  should  bounds  laraer  than 
the  battle  area  be  prescribed*  a  reduction  or  zoom-out 
illusion  is  created.  All  displays  are  generated  without  the 
need  to  store  in  memory  an  elevation  for  each  <x,y> 
1  ocat  i  on . 

The  terrain  generation  program  contains  the 
following  functions.  The  user  is  allowed  to  build  the 
parametric  data  file  under  a  filename  of  his  choosing.  He 
is  allowed  to  add*  delete  and  modify  the  file  to  reflect  the 
current  state  of  terrain  generation.  There  should  be  a 
narrative  portion  which  describes  the  function  of  the 
program  and  demonstrates  effects  of  different  input 
parameters.    The  user  should  also  be  allowed  to  familiarize 
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himself  with   the   system   by   manipulating   parameters   and 
seeing   the   results   displayed.    The   capability   to   plot 
contour  lines  of  the  user's  desired  contour  level   from   the 
defined  terrain  is  also  provided, 
b.  Position  Selection 

The  purpose  of  the  position  selection  package  is 
to  allow  the  user  of  STAR  to  select  defensive  positions  and 
rout es-o f -march  for  his  forces.  This  oackage*  like  the 
terrain  generation  package?  is  primarily  a  pre-execut i on  or 
set-up  operation  designed  to  facilitate  planning  of  a 
battle.  Execution  during  the  battle  will  give  the  user 
insight  as  to  possible  new  positions  or  tactics  as  the 
battle  orogresses.  Since  interaction  between  user  and 
simulation  is  provided  for/  the  user  may  desire  to  utilize 
information  gleened  from  the  oosition  selection  package  to 
perform  updates  during  the  simulation. 

The„position  selection  program  should  use  the 
contour  mao  generated  by  the  terrain  generation  package  and 
determine  1 i ne-of-s i gh t  (LOS)  fans  for  any  selected  position 
within   the   battle  area.  There  are  two  approaches  to  the 

representation  of  LOS  fans*  each  with  it's  own  advantaqes 
and  disadvantages.  The  first  approach  is  to  shade-in  the 
visable  area  in  the  fan.  This  method  gives  the  user  a 
distinct  impression  of  how  much  area  the  fan  covers. 
However,  specific  terrain  characteristics  within  the  fan  may 
be  hidden  from  the  user's  view.  To  counter  this 
degredation,  the  oackage  should  allow  the   user   to   display 
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the  fan  in  an  inverted  mode.  This  inverted  mode  should 
shade  the  areas  outside  the  LOS  fan  thus  allowing  the  user 
to  see  only  geographic  features  defined  within  the  fan. 
These  two  aoproaches  when  combined  should  allow  the  user  all 
LOS  related  information  concerning  that  position.  Fiaures 
4.1  and  4.2  depict  the  results  of  the  two  methods. 
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c.  Military  Symbol  Library 

The  Durpose  of  the  military  symbol  library  is  to 
allow  the  user  either  through  his  interaction  or  program 
action  to  select  a  series  of  predefined  display  device 
commands  to  draw  a  standard  military  symbol.  This  functions 
somewhat  like  a  table  lookup  orocedure  where  the  resulting 
table  entries  are  a  series  of  ^ entries  that  define  a 
particular  symbol.  The  map  overlay  disDlay  programs  must  be 
able  to  access  this  library  and  retrieve  these  instructions 
for  dynamic  display  during  the  battle. 

Military  leaders  are  innovative  when  a  standard 
symbol  has  not  been  defined  for  some  unique  apolication  and 
consequently  establish  some  symbol  to  represent  their  new 
weapon  or  unit.  The  program  should  allow  the  user  to  define 
any  additional  symbols  needed.  A  standard  checker-board 
pattern,  such  as  figure  4.3,  should  be  provided  on  the 
display  sc  reen . 


f  i  gure  4.3 
The  user  can  select  any  square  and  the   program   will   shade 
that   area.    By   continued  selection,  the  user  can  define  a 
symbol  of  his  choosing.   After   the   user   has   defined   the 
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symbol  to  his  sat i s f ac t i on ,  the  proqram  should  display  the 
symbol  for  final  aporoval  of  size  and  features.  The  symbol 
may  now  be  stored  in  the  library  for  future  reference. 


C.  USE  OF  THE  SYSTEM 

The  simulation  system  will  be  useful  in  all  phases  of 
modeling.  A  typical  senario  mav  follow  this  outline.  The 
life  of  a  simulation  beains  with  the  writina  and  debugging 
of  the  code.  The  simulation  implementer  may  sit  in  his 
office  and  enter  the  code  through  a  console  as  ooposed  to 
punching  data  cards  and  feeding  them  into  a  card  reader.  As 
the  implementer  finishes  entering  the  code/  he  may  now 
compile  the  program  and  correct  any  syntax  errors  from  the 
console.  Execution  may  reveal  problems  with  his  code  that 
may  also  be  corrected  from  his  console. 

The  user  of  the  simulation  takes  over  after  the 
implementer  has  finished  and  the  model  is  ready  for  use. 
The  user  must  first  set  uo  tne  model  for  use.  This  set  uo 
is  facilitated  by  the  tutorials  provided  by  the  system.  The 
terrain  generation  package  exolains  the  method  of  generatinq 
terrain.  The  user  uses  this  terrain  package  to  generate  and 
store  the  parameter  values  necessary  to  create  and  display 
the  terrain.  Using  the  1 i ne-of -s i gh t  capability  of  the 
system^  the  user  then  selects  the  initial  positions  for  the 
elements  on  the  battlefield  using  the  LOS  fans  provided  by 
the  system . 

The  modeler  is  now  ready  to  use  the  simulation.   As   the 
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simulation  progresses*  the  user  is  able  to  monitor  the 
simulation  and  decide  when  to  interact  with  the  simulation. 
Should  he  decide  to  interact?  he  may  do  so  from  his  console 
Dy  pressing  the  ATTN  key  and  selecting  the  type  of 
interaction  desired  from  the  menu  of  possible  alternatives. 
Once  the  interaction  is  accomD 1 i shed,  the  simulation 
continues.  The  user  notes  the  effect  of  his  interaction  and 
wonders  if  the  outcome  would  change  had  the  interactive 
input  been  different.  He  elects  to  return  to  the  point  of 
input  and  experiment  with  a  different  course  of  action. 
Again*  he  presses  the  ATTN  key  and  this  time  he  chooses  the 
option  to  repeat  the  simulation  from  a  specified  point. 
Having  changed  his  inout*  the  user  elects  to  continue  with 
the  simulation.  The  simulation  continues  until  termination. 
Post  execution  analysis  is  accomolished  through  the 
creation  of  written  reports  by  the  reoort  writer  and  the 
answering  of  Questions  by  the  inguiry  routine.  At  this 
point  the  user  may  still  elect  to  investigate  behavior  by 
returning  to  a  given  point  and  resuming  execution.  Upon 
completion  of  analysis*  the  user  may  elect  to  destroy  the 
simulation  files. 
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V.  ANALYSIS  OF  CURRENT  STAR 


A.  GENERAL 

The  analysis  conducted  on  the  current  version  of  STAR 
was  performed  in  the  general  areas  of  program  structure/ 
control  structure/  storage  optimization  and  subroutine 
analysis.  Certain  guidelines  were  used  in  the  analysis  of 
the  current  version  of  STAR.  The  programming  language  used 
is  SIMSCRIPT.  The  methodology  used  in  the  simulation  will 
be  left  to  the  programmer  and  comments  will  be  limited  to 
programming  techniques. 


8.  STRUCTURE 

The  SIMSCRIPT  programming  language  has  the  capability  to 
be  both  readable  and  structured.  Readability  and  structure 
allow  the  program  to  be  maintained  by  persons  other  than  the 
original  writers.  This  capability  of  the  language  is  not 
being  fully  exploited.  Good  readaoility  facilitates  ease  of 
maintenance  and  debugging.  To  attain  the  desired  level  of 
readability  several  principles  must  be  followed. 
Indentation  should  be  present  to  offset  the  control 
structure  from  the  code  that  is  contained  within  that 
structure.  For  example/  should  the  "if"  in  an  "if  else" 
structure  be  indented  five  spaces/  the  "else"  should  also  be 
indented   the   same   number   of   spaces.    Only   one   source 
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statement  should  be  allowed  to  a  line.   All  local   variables 

should  be  defined  rather  than  allowing  the  default  values  of 

SIMSCRIPT  to  take   precedence.    Variable   names   should   be 

obvious   as   to  their  representation/  since  SIMSCRIPT  allows 

long  variable  names.   Many  cases   of   short   variable   names 

occur   in  the  STAR  orogram  either  through  ease  of  use  or  bad 

programming  practices.   These  shorter   names   contribute   to 

ambiguity   and   confusion.   One  example  of  lack  of  structure 

is  seen  in  the  following  code   extracted   from   the   current 

model  : 

until  j  j  i  =  1 r    do 

let  t arget (name ( t ank ) , 2 )  =  he  .  drag ( t an* ) 

let  he .drag( t ank )  =  0  let  mv . s t at e ( t ank )  =  1 

let  defnum(tank)  =  1 

let  j  j  i  =  j  j  i  *  1  loop 

This  code  will   be   more   readable   if   it   were   structured 

similar  to  the  following: 

unt  i 1  j  j  i  =  It 
do 

let  t  arget  (  name  ( t  ank  ),  2. )     -    he  .drag  ( t  ank  ) 
let  he.drag( tank)  =  0 
let  mv  .st at e( t ank )  =  1 
1 et  def num (tank)  =  1 
let  j  j  i  =  j  j  i  *  1 
1  OOP 

This  type  of  structure  has  two  major  benefits.    Programmers 

easily   recognise   the   scope  of  the  UNTIL  statement  and  the 

assignment  statements  are  readily  found  since  they   are   one 

per  line  and  begin  with  the  reserved  word  LET. 

Another   example   of    how    structure    may    lead    to 

understanding  is  found  in  the  following  segment  of  code  from 

the  routine  CHG . SEC . SEARCH  . 
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'dl 


"dl  1 


"dl2 


if  ess ( a )  =  1 

•  go  to  d 1 1 
el  se 

go  to  dl2 

let  pri.dir(a)  =  pi.c/2 
let  css(a)  =  0 
go  to  set 

let  zyx  =  uniform.f(0.,l.,l) 
if  zyx  ge  .5 

go  to  dl3 
el  se 

go  to  dl4 

i 

let  pri.dir(a)  =  pi.c/4 
let  ess ( a)  =  1 
go  to  set 

let  ori.dir(a)  =  3*pi.c/4 
let  ess ( a)  =  1 
go  to  set 
"set" 

Upon  examining  this  unstructured  version  of  STAR  source 
coder  it  is  evident  that  it  may  be  replaced  by  the  following 
sequence : 


"dl3 


■  d  l  a  " 


'dl 


if  ess (a )  =  1 

let  pri.dir(a)  =  di.c/2 
let  css(a)  =  0 
go  to  set 
e  1  se 

let  ess ( a)  =  1 
if  uni f orm . f ( 0 . , 1  . , 1 )  ge  .5 
let  ori.dir(a)  =  pi.c/4 
go  to  set 
el  se 

let  ori.dir(a)  -  3  *  p  i  .  c  /  4 


"set 


This  code  sequence  is  easily  understood  ana  has  -  two 
additional  benefits.  First/  this  structured  code  will 
execute  faster  due  to  fewer  transfers  of   control.    Second, 
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storage  requirements  are  reduced  since  this  version  has 
fewer  lines  of  source  code  /  thirteen  instead  of  twenty- 
four,  thereby  reducing  object  code  storage  requirements  and 
does  not  require  the  variable  "zyx". 


C.  CONTROL  STRUCTURES 

The  STAR  model  needs  extensive  optimization  in  the  area 
of  control  structures.  The  following  example  is  from  the 
routine  COMMO .PASS . TGT . 


if  pct.vis  gt  critical. value 

1 et  1 ose  =  1 

jump  ahead 
el  se 

let  lose  =  0 
here 
i  f  1 ose  eg  0 

let  aim  =  0 

return 
el  se 


This  code  sequence  is  equivalent  to  the  following 


if  pct.vis  1e  c r i t i ca 1 . va 1 ue 

let  aim  =  0 

return 
el  se 


The  sequence  may  be  reduced  even  further  if  the  variable 
"aim"  is  initialized  to  zero  since  this  is  the  majority  of 
usage  ("aim"  is  set  to  zero  four  times  as  opposed  to  one 
only  once).  This  saving  in  storage  of  object  code*  ease  of 
understanding  and  execution  speed-up  is  attained  by  testing 
"less  tr>an  or  equal  to"  as  opposed  to  "greater  than".  This 
particular  type  of  control  structure  is  used  in  other  places 
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in  the  program  as  well. 

Another  common  control  structure  abuse  is  observed  in 
the  routine  RES4.  This  routine  has  seven  "do  loops"*  all 
indexed  from  1  to  2.  These  looos  may  be  combined  into  one 
control  structure  which  will  result  in  a  reduction  in 
execution  time  (counter  maintenance)  and  a  saving  in  object 
code  storage.  The  combination  of  "do  loops"  is  possible  in 
the  majority  of  the  STAR  routines. 

Another  optimization  technique  aoolies  to  the  routine 
PRIORITY. AND. ROUND. SELECT  with  the  follwing  code  seauence: 


let  i  =  i  -  1 

go  to  iO,  i3f  i6,  i9,  il2  per  i 

"iOw 

let  i  =0 

go  to  bands 

let  i  =  3 

go  to  bands 
"i6" 

let  i  =6 

„ go  to  bands 
"i9" 

let  f  s  <? 

go  to  bands 
*\  12" 

let  i  =  12 

go  to  bands 
"bands" 


A  little  "cleverness"  reduces  this  sequence  to 
i  s  (4  •  2)  *  3 

In  factf  in  this  routine  alone,  fifty-four  lines  of  source 
code  may  be  reduced  to  four  lines  without  loss  of  meaning. 
Benefits  of  the  reduction  include  ease  of  understanding, 
more  efficient  execution  and  less  storage  requirements. 
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D.  STORAGE  OPTIMIZATION 

Storage  optimization  can  occur  in  several  ways  in  the 
STAR  model.  Appendices  C  and  0  present  the  storage 
reguirements  of  the  current  unstructured  model.  The 
"complexity"  item  under  each  routine  analysis  in  Appendix  B 
indicates  storage  dependencies. 

Another  area  that  deserves  .close  monitoring  is  the 
assignment  of  suoscriots  in  arrays.  An  example  of  this 
detrimental  effect  is  seen  in  the  array  called  TARGET.  The 
actual  variable  is  T ARGET ( 32 1 , 2 ) .  SIMSCRIPT  creates  a  data 
structure  with  321  pointers  to  vectors  of  length  2.  By 
reversing  the  subscripts  giving  TARGE T (2 ,  32 1 )  the  SIMSCRIPT 
compiler  stores  this  with  2  pointers  of  length  321.  This 
reversal  of  subscripts  saves  319  words  of  storage  or  1278 
bytes  of  memory.  If  at  all  possible/  subscripts  should  be 
arranged  with  the  smallest  first  and  in  increasing  order. 

Appendix  0  gives  a  summary  of  all  static  storage  arrays 
and  the  storage  reouired  if  an  optimal  assignment  of 
subscriDts  is  used.  By  this  use  of  optimal  subscripts 
approximately  12K  bytes  of  storage  may  be  saved. 


E.  SIMSCRIPT  ROUTINE  ANALYSIS 

The  SIMSCRIPT  routine  analysis  was  performed  after  a 
structured  version  of  STAR  was  produced.  All  names  are 
alphabetical  within  their  category.  For  each  subroutine  the 
following  items  were  identified: 

1.  Parameters  passed  to  the  subroutine. 
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2.  Local  variables  defined  to  that  subroutine. 

3.  Global  variables  accessed. 

4.  Variables  read  into  the  subroutine. 

5.  Variables  written  to  print. 

6.  Data  structures  created. 

7.  Data  structures  filed  into  a  predefined  set. 

8.  Data  structures  removed  from  a  set. 

9.  Data  structures  destroyed. 

10.  Vectors  or  matrix  for  which  storage  is 
reserved. 

11.  Vector  or  matrix  for  which  storage  is  released 

12.  Other  subroutines  called. 

13.  Subroutines  that  call  the  subroutine. 

14.  Events  scheduled. 

15.  Subroutine  that  schedules  the  event, 
lb.  Complexity  of  subroutine  in  regard  to 

execution  time  and  storage  regu i recent s  . 

17.  Recommended  imorovements  (excluding  general 
improvements  identified  earlier). 

18.  Any  remarks  concerning  the  subroutine  and 
values  returned  to  the  calling  program. 
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VI.  CONCLUSIONS  AND  RECOMMEND A I IONS 


The  STAR  war  gaming  model  is  written  using  sound 
modeling  techniques.  The  i mo  1 emen t a t i on  does  have  a  serious 
drawback  in  maintainability.  without  structure/  this 
proqram  is  difficult/  at  best/  to  understand  and  will  be 
extremely  difficult  for  anyone  other  than  the  actual  code 
writers  to  maintain.  The  current  version  of  STAR  is  at  this 
time  undergoing  extensive  modification  to  give  the  program 
structure  and  to  attemot  to  gain  efficiency  to  both  storage 
and  execution. 

This  thesis  is  a  oreliminary  desian  and  therefore  only  a 
preferred  solution  was  given.  As  the  preferred  solution  is 
developed  at  a  later  time*  more  detail  may  be  given  as  to 
the  final  implementation  of  the  STAR  moael.  The 
i mp 1 emen t a t i on  - o f  STAR  using  the  ooeratinq  system  approach 
may  be  attempted  here  at  the  Naval  Postqraduate  School.  The 
features  described  that  are  necessary  to  implement  the 
proposed  enhancements  are  found  in  the  MULTICS  operating 
system  from  Honeywell  Information  Systems/  Inc.  which  is 
available  on  the  ARPANET.  This  availability  gives  the 
school  the  opDortunity  for  further  study. 

One  of  the  most  beneficial  short  term  improvements  that 
can  be  made  is  to  obtain  an  interactive  SIMSCRIPT  compiler. 
The  interactive  comoiler  may  be  obtained  free  of  charge  from 
Consolidated   Analysis   Centers*   Inc.   unaer  the  university 
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grant  oroqram . 

Further  experimentation  with  graphical  displays  may  be 
made  at  the  Naval  Postgraduate  School  utilizing  the  research 
comDuter  in  the  school  graphics  laboratory.  This  comouter 
may  be  used  as  a  remote  terminal  to  the  w.R.  Church  Computer 
Center  and  graphics  disolays  oroduced  on  the  terminals  in 
the  1 aborat ory  . 

The  STAR  w  a  r  g  a  m  e  orovides  excellent  opportunity  for 
further  computer  science  thesis  work.  Additional  thesis 
material  may  include  optimization  of  terrain  disDlay  using 
the  parametric  method  of  terrain  reoresen t a t i on .  Thesis 
work  in  the  area  of  ooerating  systems  may  include  actual 
implementation  of  the  STAR  model  on  the  ARPANET.  Work  in 
the  database  area  will  be  reguired  to  develoo  the  inquiry 
caoability  and  tne  reoort  generator. 
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APPENOEX  A 

AN  INTRODUCTION  TO  INTERACTIVE  TERRAIN  REPRESENTATION 
UTILIZING  PARAMETRIC  TERRAIN  GENERATION 

I.  INTRODUCTION 

This  tutorial  has  been  develooed  to  allow  interactive 
use  of  parametric  terrain  generation.  Currently  mechanisms 
exist  for  ouildina  and  modifyinq  the  inout  file  required  for 
the  generation  of  terrain  features  and  displaying  contour 
lines  of  the  user's  desired  level.  Due  to  modular  design* 
further  terrain  enhancements  such  as  three-dimensional  views 
from  any  ooint  may  be  developed  and  incorporated  into  the 
existing  program. 

Parametric  terrain  generation  uses  as  inout  parameters 
the  x  and  y  locations  of  the  center  of  the  hill  (xc  and  yc)/ 
the  elevation  at  that  <xc»yc>  location  (peak)/  tne 
eccentricity  of  the  hill  (ecc)f  the  height  of  the 
parameterized  hill  (ht)/  the  angle  of  rotation  of  the  hill 
from  an  East-West  axis  (angle)  and  the  spread  of  the  hill 
(sprd).  For  each  set  of  hill  values  there  is  a  base 
altitude/elevation  (oasealt)  associated.  This  base  altitude 
is  the  elevation  of  the  lowest  ooint  in  the  terrain  area 
that  is  being  modeled.  The  eccentricity  of  the  hill  (ecc) 
is  tne  ratio  of  major  axis  to  minor  axis  (major-axis/minor- 
axis)   for   the  hill  under  consideration.   The  spread  of  the 
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hill  is  considered  to  be  the  distance  along  the  major-axis 
for  the  elevation  to  drop  fifty  (50)  meters.  Fiqures  A-l.l 
through  A-1.5  graphically  explain  these  parameters. 


FIGURE  A-l.l 


FIGURE  A-1.2 


minor 
axis 


ecc  =  major/minor 

FIGURE  A-1.3 


maj  or 
axis 


1  10 


FIGURE  A-l.a 


FIGURE  A-1.5 
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II.  HARDWARE  REQUIREMENTS 


A.  INTRODUCTION 

The  display  hardware  utilized  in  the  develooment  is 
centered  around  the  TEKTRONICS  4014-1  storage  tube  granhics 
display  system.  It  has  a  19  inch  storage  tube  as  a  display 
medium.  Associated  with  the  404  4  is  a  standard  ASCII 
keyboard. 

A  VERSATEC  MATRIX  crinter  is  accessable  through  the 
POP  11-50  and  allows  hard  copy  generation  from  the  4014 
disolay.  A  hard  cooy  of  the  4014  disolay  screen  can  be 
obtained  by  depressing  the  cooy  key  locatea  on  the  upper 
right  portion  of  the  keyboard. 

Tne  POP  11-50  with  the  UNIX  timesharing  system  is 
utilized  and  assumes  the  4014  is  a  conventional  alphanumeric 
CRT  allowing  the  user  to  "login"  normally.  Section  IV 
discusses  these  "login"  procedures. 


B.  SYSTEM  OPERATION 

The  4014  is  powered  on  by  turning  the  off-on  switch/ 
located  under  the  keyboard  about  one  foot  from  the  floor/  to 
the   on   oosition.   After   turning   the   device    on,  wait 

aDprox i matel y  30  seconds  before  proceeding  to  allow  the 
aevice  to  warm  up.  The  screen  will  appear  a  bright  green  and 
now  must  be  erased  by  depressing  the  page  reset  key  on  the 
upper  left  portion  of  the  keyboard.   Should  a  residual  image 
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appear  on  the  screen,  wait  aoorox i mat e 1 y  15  seconds  and 
depress  the  page  reset  key  once  again.  Insure  that  the  moae 
toggle?  located  above  the  page  reset  key?  is  in  the  online 
position  rather  than  local.  Depress  the  carriage  return  and 
wait  for  the  UNIX  timesharing  system  to  request  "login". 
Follow  normal  POP  11-50  login  procedures. 
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III.  DESCRIPTION  OF  PROGRAM  FUNCTIONS 


A.  MAIN 

The  main  program  requests  the  name  of  the  data  file 
that  the  user  desires  to  operate  on  durinq  this  terminal 
session.  The  user  enters  the  filename,  upon  request  in 
either  upoer  or  lower  case  letters*  that  he  either  desires 
to  use  or  create.  The  filename  is  limited  to  eight 
characters  but  the  user  may  specify  any  length  filename  and 
the  orogram  will  only  use  the  first  eight/  terminating  all 
others.  For  this  reason  the  first  eiqht  characters  of  any 
filename  should  be  uniaue.  If  the  filename  is  not  an 
existinq  file,  the  program  will  create  it  for  the  user.  If 
the  file  does  exist*  the  oroqram  will  open  that  file  for 
read  and  write  access  to  the  user.  A  command  list  is 
displayed  next  to  allow  the  user  to  select  that  function  he 
desires  ana  enter  the  aopropriate  commana  code  when  promoted 
by  the  orogram.  The  main  program  is  developed  around  a  CASE 
statement  to  allow  the  user  to  Derform  his  desired 
functions.  Control  remains  in  this  CASE  statement  until  the 
user  elects  a  code  of  "7"  to  terminate  the  session.  When 
the  user  selects  code  7  the  orogram  displays  the  current 
state  of  the  data  file  that  the  user  selected  during  the 
beginning  of  the  session  on  the  4014  and  uoaates  the  file 
for  future  use.  Should  the  user  not  desire  to  retain  the 
current  cooy  of  the  file*  he  may  exit  the  orogram  by 
depressing   the   rub-out   key   located   on   the   lower  right 
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portion  of  the  keyboard.  (This  method  of  program  termination 
is  not  recommended  as  a  short-cut  however.) 


B.  ADD 

The  add  function  allows  the  user  to  add  another  set 
of  hill  values  to  the  data  file  specified  in  the  beginning 
of  this  terminal  session.  Addition  of  hill  values  is 
accomplished  by  adding  them  to  the  end  of  the  data  and 
incrementing  the  numoer  of  hills  on  the  file.  The  program 
will  prompt  the  user  for  each  data  item  required  for  the 
hill  and  give  the  user  the  option  of  adding  multiple  hills 
or  only  a  single  hill.  All  hill  values  are  floating  point 
numbers*  however*  the  user  need  not  specify  a  decimal  ooint 
if  that  value  is  a  whole  number  since  the  program  is  capable 
of  interpretation  in  this  case. 


C.  BUILD 

The  build  function  gives  the  user  the  capability  to 
initially  build  the  file  specified  during  the  beginning  of 
the  terminal  session.  Care  must  be  taken  to  prevent 
building  a  file  that  already  exist  since  the  building 
process  will  over -write  all  data  previously  resident  on  that 
file.  Building  is  accomplished  by  requesting  from  the  user 
the  number  of  hills  he  desires  to  load  to  the  file.  Next 
the  program  will  prompt  the  user  as  in  the  add  function  for 
all  neccessary  hill  values.   The  orogram  will  allow  the  user 
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to  only  build  one  file  Der  terminal  session.  However; 
should  the  user  desire  to  ouild  multiple  files  he  may  do  so 
by  building  the  first  one  and  then  enter  a  command  code  of 
to  exit  the  proaram.  Subseauent  file  building  is 
accomplished  by  repeating  this  same  procedure. 


D.  CHANGE 

The  chanae  process  is  actually  a  modify  orocess  since 
it  allows  the  user  to  change  or  modify  any  sinqle  hill  data 
item  or  all  data  items  for  a  hill.  The  Drogram  promots  the 
user  for  the  hill  number  he  desires  to  change*  allows  the 
user  to  select  the  data  item  to  be  cnanqed  and  then  requests 
the  new  value  that  is  to  be  substituted.  The  change  function 
will  allow  the  user  to  change  one  hill  or  many  hills  by 
asking  the  user  if  he  has  any  more  changes. 


E.  OELETE 

The  delete  function  allows  the  user  to  delete  a 
comolete  set  of  hill  values  for  the  hill  number  specified 
from  the  data  file.  Deletion  is  accomplished  by  requestinq 
the  number  of  the  hill  that  the  user  desires  to  delete* 
locatinq  that  set  of  hill  values  and  shifting  all  higher 
hill  number  values  down*  overwritting  the  deleted  hill  and 
decrementing  the  number  of  hills.  It  is  recommended  that  if 
multiple  hills  are  to  be  deleted*  the  highest  hill  number  be 
used  first  to  prevent  the  user   from   losinq   track   of   the 
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current  hill  numbers  since  the  deletion  process  also 
logically  decrements  the  hill  number.  Multiple  deletes  mav 
be  accomplished  since  the  program  will  ask  the  user  if  he 
desires  to  delete  another  hill. 


F.  PLOT 

The  plot  function  uses  the  parametric  input  data, 
which  is  located  on  the  file  specified  by  the  user,  and 
generates  contour  lines  of  the  user  specified  contour 
interval.  The  program  o  r  o  m  p  t  s  the  user  for  the  minimum  and 
maximum  x  locations,  the  minimum  and  maximum  y  locations, 
the  contour  interval  desired  and  the  minimum  elevation  in 
the  area  to  be  displayed. 


G.  MISCELLANEOUS 

The  first  miscellaneous  routine  to  be  discussed  is 
the  "writefile"  routine.  This  routine  restores/writes  the 
hill  data  from  memory  to  a  secondary  storage  (disk)  file  for 
suDseauent  use  by  the  user.  The  number  of  hills  is  written 
first  followed  by  all  x  locations  (xc).  The  file  structure 
is  completed  by  writing  the  entire  y  locations  (yc) /  hill 
spread  values  in  the  x  direction  (sx),  spread  values  in  the 
y  direction  (yc)/  the  rotation  values  respectively  and 
c 1 os  i  ng  the  file. 

The  "readfile"  routine  functions  like  the  "writefile" 
function   but   loads   the   hill   values   from   the  secondary 
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storage  (disk)  file  into  memory.  The  filename  used  is  that 
specified  by  the-  user  at  the  beginning  of  the  terminal 
sess  i  on . 

The  "printfile"  routine  displays  to  the  4  0  1  U  the  hill 
data  located  in  memory  starting  with  hill  number  one  and 
continuing  to  the  number  of  hills  that  are  being  used  in 
this  session'. 

The  "invalidcmd"  routine  produces  aoprooriate  error 
messages  to  be  displayed  on  the  4014  for  the  user.  The  user 
must  heed  the  error  message  and  take  appropriate  action 
accordi  ng  1  y . 

The  "cmdlist"  routine  disolays  all  function  codes  to 
the  user.  It  is  from  this  list  that  the  user  must  select 
the  command  code  cor resoonai nq  to  the  function  desired  and 
enter  it  when  oromotea  oy  the  orogram.  All  commands  must  be 
followed  by  a  carriage  return. 


IV.  SYSTEM  USE 

To  initiate  the  program  execution  after  powering  on  the 
4014  the  following  procedures  must  be  followed.  The  first 
step  is  to  login  to  the  UNIX  system  with  a  name  of  "parry" 
and  a  oassword  of  "parry".  (Note  all  entries  are  lower  case 
letters.)  The  second  steo  is  to  enter  "terrain"  followed  by 
a  carriage  return  and  the  Drogram  will  begin  execution 
prompting  the  user  as  needed  to  steo  the  user  through  the 
reauired  procedures. 
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PARAMETERS  : 
a 

LOCAL  VARIABLES 
a 

rnd 


APPENDIX  B 

AMMO. CHECK 
NUMBER  BYTES  OBJECT  CODE  :  49b 

rnd 

answe  r 


GLOBAL  VARIABLES 

ap.tow 

aw2 .or . adm 

c.2 

wpn .  type 


awl  .or.msl 3 

c.l 

he .draa 


CALLED  BY  : 

priori  ty. and. round. select 

t72. tactics  we. miss 

COMPLEXITY  :   Constant   storage   requirement   and   execution 
t  i  me . 

REMARKS  :  This  routine  returns  the  value  of   answer   to   the 
ca 1 1 i  ng  rout  i  ne . 
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ARTY. IMPACT 


NUMBER  BYTES  OBJECT  CODE  :  1312 


PARAMETERS 


i  d.bt  ry 

i  d. f dc 

i  d.  f  o 

i  d.mi  ss  i  on 

LOCAL  VARIABLES  : 

ans 

est  i  mat  e .0  f . t  i  me 

i 

i  d.bt  ry 

i  d. f dc 

i  d .  f  o 

id.mission 

J 

k 

A 

m 

rg 

t  i  me 

t  i  me. 1 

t  i  me .2 

t  i  me  .  3 

t  i  me  .  4 

t  i  me .5 

t  i  me  .  6 

t  i  me . 7 

w i t  h  i  n  .  to  1 erance 

X  X 

yv 

GLOBAL  VARIABLES  : 

ca 1 i  ber 

debuq 

del  .1 

del  .2 

error .code 

gsrs  .code 

gt . f  i  na 1 . rg 

last.fo.rg 

miss. tolerance 

msn  .name 

msn . t  i  me 

my . rad  i  o 

no. missions.fi  red 

now .firing 

num.adj .rounds 

num . dp  i  cm  .  1 ef  t 

rate. of . f  i  re 

rd. 1 .error 

rd .2 .error 

st.fi  r  i  ng 

thefa 

t  i  me  .  v 

vol  ley 

vol  leys.to.fi  re 

wh  i  ch . vo 1 1 ey 

x .cur  1 

x .curl 

x . f ut ure . 1 oc 

y .cur  1 

y . cur4 

y • future . 1 oc 

WRITES  : 


i  d.  f  o 

i  d. f dc 

vol  leys.to.fi  re 

wi  t  h  i  n . t ol erance 


i  d.bt  ry 
msn  .name 
num.adj .rounds 
t  i  me  .  v 
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ARTY. IMPACT  (cont) 


CALLS  : 

arctan.f 

assessment 

error 

pos i  t  i  on .update 

pr i  nt 1 

SCHEDULES  : 

busy . radi  o.net 
guns .firing 

SCHEDULED  BY  : 

guns .firing 

COMPLEXITY  :  Execution   is   linear   on   vo 1 1 ey s . t o . f i re   but 
constant  storage. 


art y . t  i  me 

di  st 

new . 1  oca t  i  on 

print 

t  racer 


end .of. mission 
open.radio.net 


ARTY. TIME 

NUMBER  OF  BYTES  OBJECT  CODE 


alb 


PARAMETERS  : 
a 

LOCAL  VARIABLES  : 

a 

GLOBAL  VARIABLES  : 

f a . t  i  me. de 1 tas 


del .time 


rn . st  ream 


CALLS  : 


norma  1  .  f 
un  i  f orm  .  f 


t  racer 


CALLED  BY  : 

arty . i  moac t 

checking.guns.avai labi 1 ity 

commo . at t empt  end.of .mission 

f dc .processi ng  updat e .c 1  us t er 

COMPLEXITY  :  Constant  execution  time  and  storage. 

REMARKS  :  Returns  the   value   of   del. time   to   the   calling 
rout  i  ne . 
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ASSESSMENT 


NUMBER  BYTES  OBJECT  COOE  :  4528 


PARAMETERS 


i  d.bt  ry 
i  d.  f  o 


i  d. f dc 

i  d.mi  ss  i  on 


LOCAL  VARIABLES  : 
count 

di  f  ference 
i  d.bt  ry 
i  d.  f  o 

J 

1 

ok 

sig.y 

x .error 

xdi  f 

y .change 

y .norma 1 .error 

ynew 

GLOBAL  VARIABLES  : 

al i  ve.dead 

amt .of. hi  ts 

debug 

di  sp 1 acement 

f  .d 

fki  1  1 

gt  »f i  nal . rg 

kki  1  1 

lethal .radius. array 

m .  d  " 

mki  1  1 

nun  .dD  i  cm  .  1 ef  t 

num . he . 1 e  f t 

p. punch 

rn . st  ream 

t  i  m  e  .  v 

x  .current 

x  ,mp  i 

y . future . 1 oc 

z .current 


deb 
i 

id. 
id. 
-k 
m 

S  i  q 
x  .c 
x  .n 
xne 
y  .e 
ydi 


uq. count 

fdc 
mission 


.  x 

hange 

orma 1 .error 

M 

r  ror 

f 


ammun  i  t  i  on . t  ype 

cali  ber 

de  f num 

d . radi  us 

f  i  red. at 

foe 

hit. state 

1 argest .num.wpns 

1 evel .of. damage 

mf  k  i  1  1 

msn . name 

num . guns 

num .hit 

rd . of  f set 

theta 

wpn . t  ype 

x  .  f uture . 1 oc 

y  .current 

v  .mpi 
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ASSESSMENT  (cont) 


WRITES 


ammuni  t  ion. type 

de  fnurn 

f.d 

fki  1  1 

hi  t .state 

kki  11 

mfki  1  1 

name 

num  .hit 

t  i  me. v 

y .current 


ca 1 i  ber 

di  f  f erence 

f  i  red . at 

qun t ube 

i 

m  .d 

mki  1  1 

ncase 

spd 

^  .current 

z  .current 


RESERVES 


RELEASES 


CALLS 


CALLED  BY 


rd.of  f set 


rd.of  f set 


abs.f  atrit 

di  st  1 oc 

new  .coordi na t e . sy s t em  normal. f 

parameters  print 
pr i  nt 1 


arty. i mo act 


COMPLEXITY  :  Execution  dependent  on   num. guns   and   tank   in 
red. alive.   Storaae  dependent  on  1  a rges t  .  num . wpns . 


IMPROVEMENTS 


Reverse  subscripts  on  rd. offset. 
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ATRIT 
NUMBER  BYTES  OBJECT  CODE 


2256 


PARAMETERS  : 

ef ki  1  1 
kayki  1  1 
tgt  .  t 

LOCAL  VARIABLES  : 
ef ki  1  1 
f  now 
nfinow 
Sh  .t 
whoca 1 1 ed 

GLOBAL  VARIABLES  : 

al i  ve.dead 
f  .d 

mf ki  1  1 
mki  1  1 


WRITES 


efkil  1 

f  .d 

kayki  1  1 
in  f  k  i  11 

Pk 


un  i  form.f 


CALLS 


CALLED  BY  : 

assessment 
mr  1  .  i  moac t 
red. art y . f  i  res 

SCHEDULES  : 

final  .  oeat  h 

COMPLEXITY    :    Constant 
requ  i  rement  s . 


emk  i 1 1 
sh.  t 
whoca 1 1 ed 


emk  i 1  1 
kayki 1 1 

Pk 
tgt  .  t 


damage .num 

m  .d 

m  i  ne . det 

oh 


emk  i 1  1 
fki  1  1 
m  .d 
mki  1  1 


geom 

ooo  .  a  .m  i  ne 


execution 


t  i  me 


and 


s  t  orage 


12a 


ATTRITION. CHECK 

"  NUMBER  BYTES  OBJECT  CODE  :  496 

GLOBAL  VARIABLES  : 

b .pet .at  t  del t a  .  t 

n. blue. alive  n. red. alive 

re .count  p. pet .att 
r .num . a  1 i  ve 

CALLS  : 

i  n  t  .  f 

SCHEDULES  : 

at t r i t i on .chec k  s t op . s i mu 1  at i on 

SCHEDULED  BY  : 

at t p i t i on .chec k  main 

COMPLEXITY    :    Constant  execution    time    and    storage 
requ  i  rement s  . 

BASIC. LOAD 

NUMBER  BYTES  OBJECT  CODE  :  2088 

PARAMETERS  : 
a 

LOCAL  VARIABLES  : 
a 

GLOBAL  VARIABLES  : 

ao.tow  awl.op.msl3 

c . 1  c  .2 

capds  caseao 

casene  cheat 

he .dpag  h  t o 

ml  m2 

m3  name 

op.png  wpn.type 

CALLED  BY  : 

bl .create  red. create 

COMPLEXITY  :  Constant  storaqe  and  execution  time. 
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BL. CREATE 
NUMBER  BYTES  OBJECT  CODE 


282a 


LOCAL  VARIABLES  : 
i 

GLOBAL  VARIABLES  : 
ap. tow 

b .num . a  1 i  ve 

cocdr 

def num 

guntube 

mv . st  at  e 

od . rng 

pi .hat 

p  1  1 1  d  r 

p  r  i  .  d  i  r 

r  .con 

sec 

veh . t  yoe 

x .current 

Z. cur  rent 


READS  : 


CREATES 


FILES  : 


bn 

cocdr 

name 

pi t 1 dr 

sec 

won . type 

y  .current 


tank 


tank  in  b 1 ue. a  1  i  ve 
tank  in  olt.unit 


RESERVES  : 


1  i  st 


RELEASES  : 


CALLS  : 


CALLED  BY 


bl .c  reat e 


bas  i  c . 1 oad 

h  i  der 


bn 

CO 

color 

d  i  r  .of .mvmt 

)  i  st 

name 

oi  .c 

Dlt 

po  i  nt  er 

re  .  count 

rr rpo  i  nt 

target 

won . t  yoe 

y .cur  rent 

zh 


CO 

di  r.of .mvmt 

Pit 

or  i .di  r 

veh . t yoe 

x .current 


tank  in  comp  .unit 
tank  in  tanks 


e  1  ev 


ma  i  n 
COMPLEXITY  :  Storage  and  execution  deoend  on  num. alive 
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PARAMETERS 


BMP. TACTICS  . 
NUMBER  BYTES  OBJECT  COOE  :  26a 


answer 


comp  .unit 
tank 


LOCAL  VARIABLES  : 
a 

b 

GLOBAL  VARIABLES  : 

CO 

foe 

CALLED  BY  : 

t  arget .sel ec t 

COMPLEXITY  :  Constant  storage  but  execution  time  is  linearly 
dependent  on  the  number  of  tanks  in  como.unit 

REMARKS  :  This  routine  returns  the  value  of   answer   to   the 
ca 1  1 i  ng  rout  i  ne . 

BUG. CHECK 

NUMBER  BYTES  OBJECT  CODE  :  102a 

PARAMETERS  : 

a  b 


LOCAL  VARIABLES  : 
a 
be 

GLOBAL  VARIABLES  : 
CO 

de  f num 
mv.state 
range 
t  .sod 


CALLS  : 


dr .mount 


CALLED  BY  : 

i  mpac t 


SCHEDULES 


df .change 


comp .unit 

d 1 t .un  i  t 

tank 

wpn . t  yoe 


COMPLEXITY  :  Constant   storage   but   execution   in   linearly 
dependent  on  tanks  in  comp. unit 
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BUSY.RADIO.NET 
NUMBER  BYTES  OBJECT  CODE  :  2aO 


PARAMETERS  : 

i  d.  radi  o 

LOCAL  VARIABLES  : 
i  d. radi  o 

GLOBAL  VARIABLES  : 
state3 


CALLS  : 


t  racer 


SCHEDULED  BY  : 

art  y  .  i  mpac  t 


quns.fi  ring 


COMPLEXITY    :    Constant    execution    time    and 
requ  i  rement s  . 


st  o  rage 


128 


CARDIO 

NUMBER  BYTES  OBJECT  COOE  :  1280 

PARAMETERS  : 

a  b 

PC  t  •  v  i  s  r 
x 

LOCAL  VARIABLES  : 

a  ang 1 e 

area  at 

b  bt 

dd  denom 

det • t  i  me  1 ambda 

mt  p. sub  .  k 

pet. vis  per  .  f u 1 1  .expo 

p  rr 

t.c.factop  tgt. element 

GLOBAL  VARIABLES  : 

b .area  bl ue 

cbar  coIop 

di  p. of •mvmt  pi  .c 

pi . hat  ppi .di  r 

r.area  red 

SDd  x .current 

y  .current  z 1 


CALLS 


abs . f  arctan.f 

log.e.f  sin.f 


CALLED  BY  : 

step . t  i  me 

COMPLEXITY    :    Constant    execution    time    and    storage 
pequ  i  pemen t  s . 

IMPROVEMENTS  :  All  local  variables  need  to  be  defined. 

REMARKS  :  Returns  the   value   of   det. time   to   the   calling 
pout  i  ne . 
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PARAMETERS 


CHARGE 


NUMBER  BYTES  OBJECT  CODE  :  2152 


LOCAL  VARIABLES  : 
avgxc 
avgxb 
avgyc 
avgyb 
c 
k 
m 

x5 
x7 
y5 
y7 


avgx5 

avgx7 

avgyS 

avgy  7 

cc 

V 

xc 
x6 
yc 
y6 


GLOBAL  VARIABLES  : 
bn 

t  ank 

x .current 
y .current 


r  e  d . a  1  i ve 

xc 

yc 


CALLS  : 


get .up 


SCHEDULES  : 

charge 


SCHEDULED  BY  : 

charge 


1 eave .check 


COMPLEXITY  :  Execution  time  is  linear   on   number   tanks 
red. alive.   Storage  requirements  are  constant. 


i  n 
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PARAMETERS  : 

i  d.bt  ry 
i  d.  f  o 

LOCAL  VARIABLES  : 
i  d.bt  ry 
i  d.  f  o 
t  i  me 

GLOBAL  VARIABLES 
Dt  ry 


CHECK  I NG.GUNS. AVAIL ABILITY 
NUMBER  BYTES  OBJECT  CODE  :  182a 


i  d. f dc 

i  d.mi  ssion 


WRITES 


f  i  pe.di  p .center 

msn . name 

num .ad}. pounds 

queue. si  ze 

state 

st . f  i  pi  ng 


i  d .  b  t  p  y 
i  d.  f  o 
state 


i  d. f dc 

i  d .mi  ss  i  on 


debug 

label 

msn .time 

num .missions 

queue . t  i  me 

statel 

t  i  me  .  v 


i  d. f dc 

msn . name 
t  i  me  .  v 


FILES 


CALLS 


id. mission  in  howitzep. queue 


ar t y . t  i  me 


t  racer 


SCHEDULES  : 

guns . f  i  pi  ng 

SCHEDULED  BY  : 

f dc .processi nq 

COMPLEXITY    :    Constant 
pequi  pement  s . 


execution 


t  i  me 


and 


st  orage 
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CHG. SEC. SEARCH 
NUMBER  BYTES  OBJECT  CODE  :  1304 


PARAMETERS  : 
a 

LOCAL  VARIABLES  : 
a 
zy  x 

GLOBAL  VARIABLES  : 
bl  ue 
ess 

mv .state 
pi  .c 


CALLS 


set  .  sector 


xy  z 


color 

cf  i  r.of  .mvmt 
pr  i  .  di  r 


un i form.f 


CALLED  BY  : 

steD.time 

COMPLEXITY    :    Constant    execution    time    and    storage 
requi  rement  s . 

IMPROVEMENTS  :  Needs  to  oe  rewritten  to   save   44   lines   of 
source  code. 
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COMMO. ATTEMPT 

.NUMBER  BYTES  OBJECT  CODE  :  1096 

PARAMETERS  : 

id.fo  id. miss  ion 

i  d. radi  o 

LOCAL  VARIABLES  : 

id.fo  id. mission 

i  d. radi  o  time 

GLOBAL  VARIABLES  : 

error  .code  i'dl  e 

st  ate3  time.v 

wa  i  t  .  t  i  me 

PILES  : 

id. mission  in  msn. queue 

CALLS  : 

arty . t  i  me  t  racer 

SCHEDULES  : 

commo . at t emDt  fdc .process i ng 

open . radi  o .net 

SCHEDULED  BY  : 

commo  .at  t  empt 

COMPLEXITY    t    Constant    execution    time    and    storage 
regu  i  remen t  s  . 
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COMMO.PASS.TGT 
NUMBER  BYTES  OBJECT  CODE  :  488 


PARAMETERS  : 

a 

LOCAL  VARIABLES  : 
a 
ba  i  m 

r 

GLOBAL  VARIABLES  : 
bwd. 1 ook 
foe 

oo . rng 
Pit 


CALLS  : 


di  st 
s  i  ght 


ai  m 
1  ose 


critical. value 
f wd . 1 ook 
pc  t  .  v  i  s 


1  oc 


CALLED  BY  : 

t  72 . tac  t  i  cs 

COMPLEXITY    :    Constant    execution    time    and    storage 
Pegu  i  rement  s  . 

REMARKS  :  This  routine  returns   the   value   of   aim   to   the 
cal 1 i  ng  rout  i  ne. 
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COMPUTE 


NUMBER  BYTES  OBJECT  CODE  :  3528 


PARAMETERS 


f .pcv i  s 

sh.t 

LOCAL 

VARIABLES  : 

addef 1 

def 1 bi  as 

el bi  as 

f ,pcv  i  s 

i  o 

k 

pc  .  v  i  s 

Sh.t 

ve  1 

GLOBAL 

VARIABLES  : 

accht 

accmb 

addon 

ht .mov 

SDd 

x .current 

WRITES 

* 
• 

i 

1 

CALLS 

• 
• 

di  st^ 

m  i  n.  f 
t  rune  .  f 

CALLED 

BY 

• 
• 

i  mpact 

pc  .  V  1  s 
tgt  .t 


addel 
defl s  i  g 
el  si  g 
i 

s 

J 
1 

r 
tgt  .t 


ace  ke 

accms 1 
bm . mov 
p  r  o  j  o 
wpn . type 
v  .current 


geom 
subcal 


COMPLEXITY    :    Constant 
regu  i  rement  s  . 


execut  i  on 


t  i  me 


and 


st o  rage 


135 


CONVERT. BACK 
NUMBER  BYTES  OBJECT  CODE 


PARAMETERS  : 
a 

LOCAL  VARIABLES  : 
a 

GLOBAL  VARIABLES  : 
c  .bar 
de  f num 
d  .num 
micro 
p. hat 
pi ow.cond 

SDd 

t  .spd 
x.Ct 
y  .ct 
z  .ct 

2h 


CALLS  : 
CALLED  BY 
COMPLEXITY 


pop. a .mine 

1  oc 

:    Constant 
requ  i  remen t s . 


pi  . i  nt 


cbar 

d,i  r.of.mvmt 

m  .det 

mi  ne  .det 

pi  .c 

d.  v 

t  i  me . v 

v  .ms 

x  .current 

y  .current 

z  .current 


712 


execution 


t  i  me 


and 


storage 


136 


DECREMENT. AMMO 
NUMBER  BYTES  OBJECT  CODE  :  768 

rnd 


PARAMETERS  : 

a 

LOCAL  VARIABLES  : 
a 

GLOBAL  VARIABLES  : 
ap. tow 
aw2 .or .adm 
c.2 

he .drag 
won . type 

CALLED  BY  : 

f  i  re 


COMPLEXITY  :  Constant  storaae  and  execution  time. 


rnd 


awl .or .ms 1 3 

erf 
trf 
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DEFENO 

■  NUMBER  BYTES  OBJECT  CODE  :  688 

PARAMETERS  : 
a 

LOCAL  VARIABLES  : 
a 

GLOBAL  VARIABLES  : 

alive. dead  ap.tow 

defnum  fa 

mv . st  ate  name 

pi.c  opi.dir 

SDd  target 

t  i  me. v  t .spd 
wpn . type 


CALLS 


dismount  .dragon  hider 

set . sector 


CALLED  BY  : 

1  oc 

COMPLEXITY  :  Constant  storage  and  execution  time. 
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DETECT 
NUMBER  BYTES  OBJECT  CODE 


PARAMETERS  : 
a 

LOCAL  VARIABLES  : 
a 
whocal 1 ed 

GLOBAL  VARIABLES  : 

al i  ve.dead 


CALLS 


critical .value 

fa 

fki  1  1 

1 ine. of. sight .exi  sts 


list .update 
prox  i  mi  t  y .detect 
t  racer 


bwd. 1 ook 
'defnum 
fip 

f  wd  •  1  ook 
dc t . v  i  s 


1  oc 
sight 


792 


SCHEDULED  BY  : 

i  mDact  st ep  .  t  i  me 

COMPLEXITY  :  Constant  storage  and  execution  time. 

IMPROVEMENTS  :  Delete  the  variable  whocalled  -  declared   but 
unused . 


139 


DF.CHG 
NUMBER  BYTES  OBJECT  CODE  :  a96 


PARAMETERS  : 
a 

LOCAL  VARIABLES  : 
a 

GLOBAL  VARIABLES  : 

a]  i  ve.dead 

de  fnum 


color 
spd 


CALLS  : 


h  i  der 


SCHEDULED  BY  : 

bug. check 
1 eave. check 


dr .mount 
1  oc 


COMPLEXITY  :  Constant  storaqe  and  execution  time. 

DISMOUNT. DRAGON 
NUMBER  BYTES  OBJECT  CODE 


7aa 


PARAMETERS  : 
a 

LOCAL  VARIABLES  : 
a 

GLOBAL  VARIABLES  : 
defnum 
m2 

name 
pi  t 

pr i .di  r 
target 
x .current 


CALLS 


h  i  der 

set . sector 


he  .draaon 
mv . st  at  e 
oi  .c 

o 1 t  .  un  i  t 
t  ank 

wpn . t  ype 
y  .current 


1  oc 


CALLED  BY  : 

defend 

COMPLEXITY  :  Storage  requirements  are  constant  but  execution 
time  is  linearly  dependent  on  the  number  of  tanks 
in  p 1 t  .un  i  t  . 
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PARAMETERS  : 
xl 
yl 

LOCAL  VARIABLES  : 
di  st ance 
x2 
y2 


DIST 
NUMBER  BYTES  OBJECT  CODE 


x2 


CALLS 


sqrt  .  f 


CALLED  BY  : 

arty . i  mpac  t 
commo.at t  empt 
error 
f  i  re 
i  mpac t 


xl 
yl 
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assessment 

compute 

f  dc .process  i  ng 

quns.fi  rina 

new .location 


COMPLEXITY  :  Constant  storage  and  execution  time. 

REMARKS  :  Returns  the   value   of   distance   to   the   calling 
rout  i  ne . 
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DOING. CLUSTERS 
NUMBER  BYTES  OBJECT  CODE 


5048 


PARAMETERS  : 

i  d.  f  o 

pr i . va 1 

ue 

LOCAL 

VARIABLES  : 

a 
b 
i 

i 

l 
n 

prt . val 

ue 

tank 

X 

GLOBAL  VARIABLES  : 

alive .dead 

box . tol erance 

c .number . array 

di  r .of .mvmt 

f o.min. range 

name 

sod 

target 

y  .  current 


WRITES 


CALLS 


clusters 
i  d.  f  o 


abs .  f 
cos .  f 
1  oc 


CALLED  BY 


update. c luster 


name.pr i  or  i  t  y 


angl  e 

di  r 

id.fo 

k 

m 

name .priori  t  y 

s 

total  .clusters 

y 


b  .org . a  1 i  ve 

clusters 

debua 

f o  .max . range 

1  i  st 

ol d.c 1 uster. number 

stated 

x  .current 


arc  t  an  .  f 

di  m  .  f 
S  i  n  .  f 


COMPLEXITY  :  Storage  is  constant  but  execution  is  deoendent 
on  the  product  of  the  size  of  the  target  list  and 
the  total  number  of  clusters. 

REMARKS  :  Returns  the  values  of  name .or i or i t y  and  pri. value 
to  the  calling  routine. 
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PARAMETERS  : 

a 

LOCAL  VARIABLES 


OR. MOUNT 


NUMBER  BYTES  OBJECT  CODE  :  1192 


J  J  i 


GLOBAL  VARIABLES  : 
ao. tow 
tip 
m2 

name 

pi t .uni  t 
t arqet 

t  .SDd 

x .current 

CALLED  BY  : 

bug. check 

SCHEDULES  : 

df  .chq 


d  e  f  n  u  m 
he. drag 
nfv.state 
Pit 
t  ank 
t  i  me . v 
won . t  yoe 
y  .current 


1 eave .chec  k 


COMPLEXITY  :  Execution  time  increases  linear  with  number 
tanks  in  olt.unit  with  won.tyoe  =  6  and 
he  .drag ( t ank )  gt  0  and  fir(tank)  ne  1.  Storaqe  is 
const  ant . 
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PARAMETERS  : 

i  d .bt  ry 
id.fo 


END. OF. MISSION 
•NUMBER  BYTES  OBJECT  CODE  :  2704 


i  d. f dc 

id.mission 


LOCAL  VARIABLES  : 

e  s  t  i  m  a  t  e  .  o  f  •  t  i  m  e 
id.fdc 
id.mission 
t  i  me 

GLOBAL  VARIABLES  : 

amt  .ac  t  i  ve  .msns 

bt  ry 

f  i  st 

ho  1 di  ng.msns 

label 

msn.name 

msn. t  i  me 

new. 1 ocat  i  on 

queue  .size 

st atel 

t  i  me  .  v 


WRITES 


f  i  st 

id.fdc 
msn .name 


i  d.bt  ry 
id.fo 
t  i  me 


amt .msns . f  i  red 
debug 

how  i  t  zer .queue 
mission 

my . radi  O 

num .adj. rounds 

queue .time 

st. firing 

wh  i  ch . vo 1  ley 


i  d.bt  ry 

id.fo 
t  i  me  .  v 


FILES 


REMOVES 


CALLS  : 


id.mission  in  msn. queue 

id.mission  from  howitzer.aueue  and  holding. msns 


arty . t  i  me 


t  racer 


quns .firing 


SCHEDULES  : 

f o  .not  .busy 
ooen . radi  o . net 

SCHEDULED  BY  : 

arty. impact  error 

COMPLEXITY  :  Constant  execution  and  storage  reau i remen t s . 
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ERROR 
NUMBER  BYTES  OBJECT  CODE 


944 


PARAMETERS  : 
ans 

id.fdc 
i  d.mi  ss  i  on 

LOCAL  VARIABLES  : 
ans 

i  d. f dc 
i  d  .  m  i  s  s  i  o  n 
sig.y 
xdi  f 

x  .norma  1  .error 
y  .  i  mpact .poi  nt 

GLOBAL  VARIABLES  : 

ammun  i  t  i  on  .  t yoe 
error .code 
rn .st  ream 
x . future . 1 oc 


CALLS 


CALLED  BY 


SCHEDULES 


di  st 

norma  1  •  f 

pos  i  t  i  on  .update 


art  y .  i  moac  t 


i  d.bt  ry 
i  d.  f  o 


i  d.bt  ry 

i  d.  f  o 

s  i  g.  x 

tank 

x . i  mpact .point 

ydi  f 

y  .  norma  1  .error 


ca 1 i  Der 

gt  .  f  i  na 1  . 1 oc 

theta 

y.future.loc 


new.coordinate.system 
Daramet  ers 
t  racer 


end. of .mi  ss  i  on 
COMPLEXITY  :  Constant  execution  and  storage  requirements. 
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LOCAL  VARIABLES 
i 
k 

m 


FA. 1 .MAIN 
NUMBER  BYTES  OBJECT  CODE  :  4936 


GLOBAL  VARIABLES  : 

amt . ammo . t  ypes 

amt .ca 1 i bers 

amt • f  f e . vo 1 1 eys 

amt.red.batterys 

b  .  num . a  1 i ve 

box . tol erance 

cutof  f . t  i  me 

di  spl acement 

f o .max . range 

f o . veh i  c  1  e 

1 argest .num.wDns 

max. number. of. missions 

max . ranqe 

n .battery 

n .  f  o 

n . radi  o 

num. he .left 

p. punch 

rate.of.fi  re 

r .num . a  1 i ve 

r .org. a  1 i  ve 

s  i  gma .dp  i  cm 

travel .time. array 

x .cupI 

y .cur  1 


amt .bl ue.batterys 
amt . fa. time. del tas 
amt .mr 1 
-arty.pk.table 
b  .  org. a  1  i  ve 
co 1  or  1 
debug 
d. radi  us 
f o .mi  n . range 
fwO.obs.msn. tol erance 

per . f o 

mi  ss . t o 1 erance 

n  .  f  dc 

no .  range  .bands 

num  .dpi  cm. 1  eft 

num .guns 

range .bands 

red. 1  .constant 

rn . st  ream 

sa 1 vos 

tgt .acq. error 

t  r . t  i  me 

x ,cur2 

y  .cur2 
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FA. 1. MAIN  Ccont) 


READS 


amt .ammo • t  ypes 

amt.cal i  bers 

amt  »f fe»vol leys 

amt . red. bat  terys 

box • tol erance 

cutof  f  « t  i  me 

di  so  1 acement 

f o .max . range 

f o. veh  tele 

1 argest .num.wpns 

max. number. of. missions 

max  .  range 

n  .bat  tery 

n  .  f  o 

n . radi  o 

num. he .left 

p. punch 

rate.of . f  i  re 

s  i  gma .dpi  cm 

travel .time. array 

x .cur  1 

CREATES  : 

battery 

fo 

RESERVES  : 

amt .bl ue.batterys 

amt. fa. time. del tas 

amt .mr 1 

art y .pk . t  ab 1 e 

col  or  1 

debug 

d . radi  us 

f o .mi  n . range 

fwd.obs.msn. tolerance 

per .  f o 

mi  ss  .  t  o 1 erance 

n .  f  dc 

no. range. bands 

num. dpi  cm. 1  eft 

num  .guns 

range. bands 

rn . st  ream 

tgt . acg. error 

t  r . t  i  me 

y .cur  1 


fdc 

radi  o 


array .detect 

clusters 

di  sol acement 

f a  .  1 1  me. del tas 

lethal  .  rad  i  us 

red. pi  anned.fi  res 

time.l ast .cluster. update 

travel .time. array 


arty .Pk . t  ab 1 e 
c  .number . array 

f o . vehc 1 e 
range .bands 
s  i  gma . do  i  cm 
tgt .acg. error 


RELEASES  : 


CALLS  : 


prep  1 anned 


orep 1 anned 


CALLED  BY  : 

ma  i  n 

COMPLEXITY  :  Linear  on  n.fdCr   n. battery,   am t  .  ammo . t ypes   * 
amt  .ca 1 i bers i  amt  .b 1 ue .bat t ery s    *    num.guns, 

amt. calibers  *  no  .  ranqe . bands 


IMPROVEMENTS 


Reads  num  .dpi  cm . 1  eft  then  sets  to  0. 
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FA. 2. MAIN 
NUMBER  BYTES  OBJECT  CODE  :  3472 


LOCAL  VARIABLES  : 
i 
k 

GLOBAL  VARIABLES  : 

amt  .  ammo . t  yoes 
amt.caH  bers 
amt . f  f e . vol  leys 
amt  .  red. bat  t  erys 
b  .org  .a  1 ive 
cutof  f . t  i  me 
d. radi  us 
f o  .max . range 
f o  .  veh  i  c  1  e 
largest .num.wons 


J 


amt. blue. batterys 

amt .fa. time. del tas 

amt  ,mr 1 

arty. ok. table 

box . tol erance 

debug 

fa 

f o .m  i  n . range 

fwd.obs.msn. tolerance 

lethal  . radi  us 


max. number. of. mi  ssi  ons.oer. fo 

mi ss  .  tol erance  n. battery 

n  .  f dc  n . f o 

no . range .bands  n. radio 

n. tanks  Di.c 

pointing. to  p. punch 

rn. stream  r.org.alive 

r r roo  i  nt  t  ype 


WRITES  : 


amt . ammo . t  yoes 
amt  .cal i  bers 
amt  .  f  f e . vo 1  leys 
amt  .red. batterys 
box .tol erance 
debug 


amt  .bl ue.bat  terys 

amt .fa.time.del tas 

amt .mr 1 

b .org . a  1  ive 

cutoff. time 

d. radi  us 

f o .mi  n . range 

1 argest .num.wons 


f o .max . range 

fwd.obs.msn.tol erance 

max  .number. of .mi  ssi  ons.per. fo 

mi ss . to  1 erance  n. battery 

n . f dc  n . f o 

no . range. bands  n. radio 

n  .  tanks  p. punch 

r.org.alive  rn. stream 
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FA.  2.  MAIN  (cont) 

CALLS  : 

sqrt .  f 

CALLED  BY  : 

mai  n 

SCHEDULES  : 

red. art y • f i res  updat e.c 1 ust e r 

COMPLEXITY  :  Linear  on  n.fo#  amt. calibers  *  amt . ammo . t yoes  * 
9,  amt.red.batterys  -  amt.mrl 

IMPROVEMENTS  :  Combine  major  loops. 

FA. TGT. ERROR 

NUMBER  BYTES  OBJECT  CODE  :  ai6 

PARAMETERS  : 

a  1 oc .error 

LOCAL  VARIABLES  : 

a  loc.error 

GLOBAL  VARIABLES  : 

rn. stream  tgt . acq. er ror 

CALLS  : 

t  racer  uni  f orm  .  f 

CALLED  BY  : 

new.location 

COMPLEXITY  :  Constant  execution  and  storage  requirements. 

REMARKS  :  This  routine  returns  the  value  of  loc.error  to  the 
ca 1 1  i  ng  rout  i  ne. 
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PARAMETERS 


i  d.  f  o 

LOCAL  VARIABLES  : 
di  ff 
i  d.bt  ry 
i  d.mi  ssi  on 
k 
m 

t  i  me 
vol  1 eys 
yy 

GLOBAL  VARIABLES  : 

ammun i  t ion. t yoe 

amt . f f e. vol  1 eys 

debug 

error .code 

gt .final .  rg 

mi  s s  i  o n 

msn .name 

msn .  t  i  me 

n .ho  1 di  ng.msns 

process 

start 

status 

t  i  m  e  .  v 

vol  1 eys. to . f i  re 

x  .curl 

y  .curl 

y . future  .  1 oc 


FOC. PROCESSING. 
NUMBER  BYTES  OBJECT  CODE  :  3a2a 

i  d.mi  ssi  on 


WRITES  : 


FILES  : 
CALLS  : 


i 

msn .name 
queue  .size 
t  i  m  e  .  v 


i 

i  d.  f  o 

J 

1 

rg 

t  ype . ammo 

x  x 


amt .act  i  ve.msns 

busy 

do  i  cm 

fwd.obs.msn.tol erance 

gt. initial .rg 

my . radi  o 

n .  f  dc 

num. missions 

queue. s  i  ze 

s t  at e  1 

theta 

x  .cur  1 

x  .  f uture . 1 oc 

y  .cur4 


i  d.  f  o 

num  .missions 

statel 


id. mission  in  holding. msns  and  msn. queue 


arc  t  an . f 
di  st 


art  y . t  i  me 
tracer 
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FDC.  PROCESSING  Ccont) 

SCHEDULES  : 

checking.guns.avai 1 i  bi 1 i  ty 
f o.not .busy 

SCHEDULED  BY  : 

commo . at  t emot 

COMPLEXITY  :  Execution  time  is  linear  with  n.fdc  and  storage 
i  s  const  ant. 

IMPROVEMENTS  :  Combine  all  "for"  loops  into  one. 
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FINAL. DEATH 
NUMBER  BYTES  OBJECT  CODE  :  1424 


PARAMETERS  : 

a 

LOCAL  VARIABLES  : 
a 

GLOBAL  VARIABLES  : 

alive  .dead 

f.d 

f  ki  1  1 

hi  t .state 

kki  1  1 

mf  ki  1  1 

name 

num. h  i  t 

t  ime.v 

x  .current 

z .current 


WRITES 


CALLS 


de  f num 

f i  red. at 

guntube 

k.hi  t 

m.d 

mki  11 

ncase 

sod 

won . type 

y .current 


tally. hit. state 


SCHEDULED  BY  : 
at  ri  t 

COMPLEXITY    :    Constant 
requ  i  remen t  s  . 


de  f num 

f  i  red. at 

gun t  ube 

k.h  i  t 

m.d 

mki  1  1 

ncase 

sod 

won  .  t  ype 

y  .current 


f.d 
f  ki  1  1 
hit. state 
kki  11 
m  f  k  i  1  1 
name 
num  .hit 
t  i  me . v 
x  .current 
2  .current 


execution 


t  i  me 


and 


storage 
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FIRE 
NUMBER  BYTES  OBJECT  CODE  :  2212 


PARAMETERS 


LOCAL  VARIABLES  : 
a 

1  ose 
stop. count 

GLOBAL  VARIABLES  : 

al i  ve.dead 
bwd. 1 ook 
color 
de  f num 
f  ip 

f wd. 1 ook 
mz 1  .  ve 1 
pet  .  v  i  s 
p  r  o  j  o 
sched 
tgt .sc 1 
won • type 
y  .current 

CALLS  : 

decrement .ammo 
h  i  der 

set  .muzz  1 e . vel 
stop. to.fi  re 

SCHEDULES  : 

i  mpac t 

SCHEDULED  BY  : 

1 72. t  act  i  cs 

we .m  i  ss 

COMPLEXITY    :    Constant 
regui  rement  s . 


id 


id 

r 


bl  ue 

check .time 

critical .value 

foe 

fki  1  1 

mv . s  t  at  e 

od . rng 

poi  nt  er 

range 

second. shot 

t  i  me . v 

x  .current 


di  st 
1  oc 
s  i  ght 
t  racer 


t  arget  .  se 1 ec  t 
t  arqet .select 
execution    time    and 


storage 
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FIRST 


NUMBER  BYTES  OBJECT  CODE  :  288 

PARAMETERS  : 
a 

LOCAL  VARIABLES  : 
a 

GLOBAL  VARIABLES  : 

mu  range 

wpn.tyoe  ' 

CALLS  : 

t  rune  .  f 

CALLED  8Y  : 

1  ay  .  1 oad 

COMPLEXITY    :    Constant    execution    time    and    storage 
regu  i  rement  s . 

FO. NOT. BUSY 

NUMBER  BYTES  OBJECT  CODE  :  U08 

PARAMETERS  : 

i  d.  f  o 

LOCAL  VARIABLES  : 
i  d.  f  o 

GLOBAL  VARIABLES  : 

amt  .  ac t i ve .msns  idle 

st  atus 

SCHEDULES  : 

uodate.c luster 

SCHEDULED  BY  : 

end. of .mi ssi on  fdc .process i ng 

COMPLEXITY    :    Constant    execution    time    and    storage 
regui  rement  s . 
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GEOM 


NUMBER  BYTES  OBJECT  CODE  :  8080 


PARAMETERS  : 

addef 1 
def 1 bi  as 
e  1  b  i  a  s 
f ,pcv i  s 
r 
tgt  .t 

LOCAL  VARIABLES  : 
addef 1 
ai  md  i  s 
def 1 bi  as 
def 1  si  g 
e  f  k  i  11 
el b  i  as 
e  1  m  i  s 
el  si  g 
empl 
fk 
i 

J 

k 
kaypl 

1 

m 

mo 

n 

r 

Sh  .t 

tat  .'t 
ve  1 
width 
y.t 

GLOBAL  VARIABLES  : 

alive .aead 

di  r .of .mvmt 

j  norm 

1  el  1 

le31 

le71 

le81 

norseed 

P  r  o  j  o 

t  ardi  m 

won .  type 

y .current 


addel 
def 1 s  i  g 
e  1  s  i  g 
pc  .  v  i  s 

sh  .  t 


adde  1 

def di  s 

def 1 m i  ss 

di  swk 

efpl 

el  di  s 

el m  i  ss 

emk  i 1 1 

f .PC v  i  s 

gamma 

i  o 

jo 

kayki 1 1 

kk 

1 engt  h 

mk 

mo 

pc  .  v  i  s 

ro 

s  i  ze 

turret 

whoca 1 1 ed 

x  .  t 


damage .num 

hno  rm 

kki  1  1 

lel2 

le61 

le72 

le83 

oh 

sod 

veh . t  yoe 

x .current 
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GEOM  (cont)   • 

CALLS  : 

abs. f  arc  tan  .  f 

at  r  i  t  cos  •  f 

1 oadn  s  i  n  .  f 

t  rune  .  f 

CALLED  BY  : 

comDut e 

COMPLEXITY    :    Constant    execution    time    and    storage 
requi  rement  s  .  , 

GET. UP 

NUMBER  8YTES  OBJECT  CODE  :  57b 

PARAMETERS  : 

a  b 

LOCAL  VARIABLES  : 

a  o 

GLOBAL  VARIABLES  : 

ao.tow  bn 

def num  mv  .  s t  at  e 

name  red  .  a  1 ive 

tank  target 
wpn. type 

CALLS  : 

loc  , 

CALLED  BY  : 

charge 

COMPLEXITY    :    Constant    execution    time    and    storage 
requ  i  rement s  . 
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GUNS. FIRING   . 
NUMBER  BYTES  OBJECT  CODE 


1768 


PARAMETERS  : 

i d.bt  ry 
i  d  .  f  o 

LOCAL  VARIABLES  : 
i  d.bt  ry 
i  d  .  f  o 

type. ammo 

GLOBAL  VARIABLES  : 
ad j . round 
ca 1 i  ber 
gt  .  f i  na 1  .  rg 
my  .  pad  i  o 
time.v 

wh  i  ch  .  vo 1  ley 
x  .cur  1 
y  .cur  1 


WRITES 


CALLS 


SCHEDULES 


i  d.bt  ry 
i  d.  f  o 
time.v 


di  st 


i  d. f dc 

id.mission 


i  d. f dc 

i  d .  rn  i  ssion 

tof 

won . type 


ammun  i  t  i on . t yoe 

debug 

msn  .  name 

now  .  f  i  r  i  nq 

travel  .time. array 

x. future. Toe 
y  .  f ut  ure . 1 oc 


i  d. f dc 
msn  .name 
which,  vol  lev 


t  racer 


ar t  y  .  i  moac  t 
ooen . radi  o.net 

SCHEDULED  BY  : 

arty • i  moact 

checking.guns.avai labi 1 i  ty 
end . of .m  i  ss  i  on 


busy.radio.net 


COMPLEXITY    :    Constant 
requ  i  rement s . 


execut  i  on 


t  i  me 


and 


s  t  orage 
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PARAMETERS  : 

a 

LOCAL  VARIABLES  : 
a 
whocal 1 ed 

GLOBAL  VARIABLES  I 

al i  ve.dead 

mv.state 


HIDE 
NUMBER  BYTES  OBJECT  CODE  :  1536 

whoca 1 1 ed 


CALLS  : 


h  i  der 


hold 


def num 


rel oad 


SCHEDULES  : 

h  i  de 

SCHEDULED  BY  : 
hi  de 
we . h  i  t 


re  1 oad 
we .mi  ss 


COMPLEXITY  :  Constant  storaqe  and  execution  time. 

HIDER 
NUMBER  BYTES  OBJECT  CODE  :  320 

PARAMETERS  : 

a 


LOCAL  VARIABLES  : 
a 
aname 

GLOBAL  VARIABLES 
def num 
name 
zh 


adef 
w  t  ype 


micro 
wpn . type 


CALLS  : 


mcov 


CALLED  BY  : 

bl  .create 
df  .chg 
fire 

red.c  reat e 
we . h  i  t 


defend 

di  smount .dragon 

h  i  de 

t  arget .select 

we  .m  i  ss 


COMPLEXITY  :  Constant  storage  and  execution  time. 
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IFV. TACTICS 
NUMBER  BYTES  OBJECT  CODE  :  352 


PARAMETERS  : 
a 

LOCAL  VARIABLES  : 

a 
b 

GLOBAL  VARIABLES  : 
foe 
pi t .uni  t 


CALLS  : 


un i form.f 


answer 

z 


pit 

tank 


CALLED  BY  : 

target . sel ec t 

COMPLEXITY  :  Execution  is  linear  on   tank   in   pit. unit 
storage  is  constant. 


and 
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IMPACT 


NUMBER  BYTES  OBJECT  CODE  :  4488 


PARAMETERS  : 
a 
y 

LOCAL  VARIABLES  : 
a 

dt 
r 

whocal 1 ed 
y 

GLOBAL  VARIABLES  : 

a  1 i  ve.dead 

check  .  t  i  me 

critical  .value 

dam  .array 

fa 

f  i  red. at 

f  Ic  i  11 

f wo. 1 ook 

guntube 

k.hi  t 

kki  1  1 

mf ki  1  1 

mmm 

name 

num .hit 

pc t , vi  s 

pro  jp 

SDd 

tow . kount 
wpn • t  ype 
y  .current 


id 


answer 

id 

stopcount 


bwd .  1 ook 

CO 

damage .num 

de  f num 

f.d 

fip 

foe 

0  •  amm 

hit. state 

killer 

m  .d 

mki  1  1 

mv  .  s t  at  e 

nc  ase 

pcb  .vis 

poi  nter 

range 

t  i  me  .  v 

ttt 

x  .current 

z .current 


WRITES  : 


def num 

f  i  red. at 

g .  amm 

h  i  t  .state 

kki  1  1 

mf ki  1  1 

name 

num  .hit 

pro  j  O 

spd 

ttt 

x .current 

z  .current 


f.d 
fki  1  1 
guntube 
k  .hi  t 
m  .d 
mki  1  1 
ncase 
pcb  .vis 
range 
t  i  me  .  v 
wpn . t  yoe 
y  .cur  rent 
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IMPACT  (cont) 


CALLS  : 


bug. check 
di  st 
Joe 

sight 
tally.hit.st ate 

we . h  i  t 


compute 
list. updat e 
sector .check 
st op. to.fi  re 
t  racer 
we  .mi  ss 


SCHEDULES  : 

detect 
new . f o 


mr 1  .  i  mpac  t 


SCHEDULED  BY  : 
fire 


COMPLEXITY    :    Constant 
requ  i  rement  s . 


execution    time    and    storage 
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ITV. TACTICS  . 

NUMBER  BYTES  OBJECT  CODE  :  352 

PARAMETERS  : 

a  b 

LOCAL  VARIABLES  : 

a  answer 

b  z 

GLOBAL  VARIABLES  : 

foe  ■  pit 

pi t  .uni  t  tank 

CALLS  : 

uni  form . f 

COMPLEXITY  :  Execution  time  linear  on  tanks  in  olt.unit   and 
storage  is  constant. 

CALLED  BY  : 

target . sel ec t 

REMARKS  :   Returns   the   value   of   answer   to   the   callina 
rout  i  ne . 

LAY. LOAD 

NUMBER  BYTES  OBJECT  CODE  :  2136 

PARAMETERS  : 

a  x 

LOCAL  VARIABLES  : 

a  time 

x 

GLOBAL  VARIABLES  : 

pro  j  o  wpn . type 

CALLS  : 

first  max.f 

norma  1  . f 

CALLED  BY  : 

t72. tactics  target .select 

we .m  i  ss 

COMPLEXITY    :    Constant    execution    time    and    storage 
regu  i  remen t  s  . 

REMARKS  :  Returns  the  value  of  time  to  the  calling  routine. 
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PARAMETERS 


LEAVE. CHECK 


NUMBER  BYTES  OBJECT  CODE  :  9768 


LOCAL  VARIABLES 
a 

bb 
cb 
ij 
i  m 


b 

be 

cc 

i  k 


GLOBAL  VARIABLES  : 

3D . tOW 

bn 
color 

de  f  num 
hasty 
mv .state 
Pit 
red 
t  ank 
t .dead 
t  .sod 
won . t  ype 


b  1  ue 

CO 

comp .unit 

fa 

m2 

name 

o 1 t.unit 

red .a  1  i ve 

t  arget 

t  i  me*v 

upoer .  1 ower 


CALLS  : 


dr  .mount 
t  rune  .  f 


1  oc 


CALLED  BY  : 

tally. hit. state 


SCHEDULES  : 

charge 


df  .chg 


COMPLEXITY  :  Execution  time  deoends  on  tanks  in  comp. unit 
tanks  in  Dlt.unit  and  storaae  is  constant. 
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PARAMETERS  : 
a 
1  ose 

LOCAL  VARIABLES  : 
a 

count 
i 
si  ze 

GLOBAL  VARIABLES  : 

alive .dead 
list 


LIST. UPDATE 
NUMBER  BYTES  OBJECT  CODE  :  1840 

b 

whoca 1 1 ed 


RESERVES  : 


1  i  st 


RELEASES  : 


1  i  st 


CALLS  : 


b 

flag 
1  ose 

whoca 1 1 ed 


fa 

t emo . tgt 


m  i  n  .  f 


di  m  .  f 

un i f orm . f 

CALLED  BY  : 

detect 

prox  i  mi  ty .detect 

SCHEDULES  I 

target . sel ec t 

COMPLEXITY  :   Execution   time   and   storage   are   linear   on 
e 1 ement  s  in  list. 


i  mpac  t 

t  arget  .  se 1 ec  t 
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LOC 
NUMBER  BYTES  OBJECT  CODE 


1096 


PARAMETERS 


t  ank 

LOCAL  VARIABLES  : 
t  ank 

GLOBAL  VARIABLES  : 

al  i  ve.dead 

CO 

de  f num 
mki  1  1 

mv.state 
Pit 

SDd 

wpn .  t  ype 


b  1  ue 

color 

fist 

m  .  r  e  d  .  a  1  i  ve 

name 

red 

t  arget 


REMOVES 


tank  from  red.al i ve»  comp.unit  and  pit. unit 


RELEASES  : 


CALLS 


CALLED  BY 


1  i  st 


convert .back 
param .set 


assessment 

detect 

doi  ng.c 1 usters 

get .up 

1 eave .chec  k 

mr 1  .  i  mpac t 

red. art y . f  i  res 

1 72  .  tact  i  cs 


SCHEDULES 
COMPLEXITY 


df  .chq 

t    Constant 
requi  rement s. 


defend 


commo .pass . t  gt 

di  smount  .draaon 

f  i  re 

i  moac t 

1 oc  .update 

pos  i  t  i  on. update 

s t  op . s  i  mu 1  at  i  on 

target  .  sel ec  t 


execut  i  on 


t  i  me 


and 


s t o  rage 
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LOC.UPOATE   • 
NUMBER  BYTES  OBJECT  CODE  :  38a 


LOCAL  VARIABLES  : 
t  ank 

GLOBAL  VARIABLES  : 

alive .dead 


CALLS  : 


1  oc 


SCHEDULES  : 

1 oc . uoda t  e 

SCHEDULED  BY  : 

1 oc  .uodat  e 


del ta.t 


red.c  reate 


COMPLEXITY    :    Constant    execution    time    and 
requ  i  rement  s . 


storage 
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MAIN 


NUMBER  BYTES  OBJECT  CODE  :  5928 


LOCAL    VARIABLES     : 
cnurn 
J 

GLOBAL  VARIABLES  : 
area 

be .count 
b.pct .at  t 
case 
cdt  i  me 
constant 
d .  num 
def . t  i  me 
ds  1 

guntube 
i .dead 
j  norm 
1 i  nes  .v 
mmm 
ncase 
nnn 

n .pi  at oon . 1 eader 
pca.vis 
pcb. v  i  s 
pi atoon . 1 eader 

D.  V 

r . area 

r  .  num . a  1 i  ve 

seed. v 

s  2  . 1 1  m  e 

t  arget 

temp, tgt 

ttt 

v.ms 

x.ct 

y  .ct 

z.ct 


i 
pnum 


b  •  area 

b .num . al i ve 

bt  t  i  me 

c  .bar 

company .commanaer 

critical .value 

dam . a  r  ray 

del ta.  t 

ds2 

hast  y 

i  t  .dead 

1  in 

m  .det 

mu 

n.  company. commander 

norseed 

oca  .unc 

ocb  .unc 

p  .hat 

pi  .c 

qa 

re  .count 

r .pc t . at  t 

s  1  .  t  i  me 

steps 

t  .dead 

tgt sc 1 

upper . 1 ower 

w  •  k  .  c 

x . st  oo 

y . stop 

zh 


READS 


b .num. alive 

cnurn 

dsl 

gunt  ube 

ncase 

r .num . a  1 i  ve 

seed,  v 

x . stop 


b .pc t  .at  t 

del ta.t 

ds2 

mu 

onum 

r .pet . at  t 

upper . 1 ower 

y . stop 
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MAIN  (cont) 


WRITES  : 


CREATES 


RESERVES 


b.pct  .at  t 
norseed 
upper. 1 ower 
y  .stop 


guntube 
r.DCt.att 
x . stop 


every  p 1  at oon . 1 eader   every  company .commander 


bbbpoi  nt 

dam . array 

dsl 

i .dead 

m.det 

pea  .unc 

peb .unc 

p. hat 

P.  v 

rrpooi nt 

t  .dead 

tgtscl 

x.ct 

z  .ct 


c  .bar 

d .  num 

ds2 

i  t .dead 

mu 

oca.vis 

peb  .  v  i  s 

pi  .c 

qq 

target 

t  emD .  tqt 

v  .ms 

y.ct 

zh 


RELEASES 


f a . 1 .ma  i  n 
res  1 
res3 
res5 


f a .2. ma  i  n 
res2 

res4 


CALLS  : 


SCHEDULES 


bl  .create 

fa. 1. ma  in 

i  ni  t  rd 

res  1 

res3 

res5 

va 1 s  .  f or .case 


at  t  r i  t  i  on .check 
st ep. t  i  me 
stop.s  i  mu 1  at  i  on 


cos .  f 

f a .2 .ma  i  n 

1  oadn 

res2 

res4 

set . sec  tor 


new .forces 

s t op . s  i  mu 1  at  i  on 


COMPLEXITY  :  Execution  is  dependent  on  the  number  of  tanks. 
Storage  is  deoendent  on  the  number  of  platoon 
leaders*  the  number  of  company  commanders  and  the 
number  of  elements  in  r.  num.  alive  and  b.  num. alive. 


REMARKS 


Main  routine  starts  the  simulation. 
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MRL. IMPACT 
NUMBER  BYTES  OBJECT  CODE  :  25o8 


PARAMETERS 


x  .  1  oc 

LOCAL  VARIABLES  : 
i  d.bt  ry 
no. mens, f  i  red 
red. 2 .cons  t  ant 
x 
y .  1  oc 

GLOBAL  VARIABLES  : 

a  1 i  ve.dead 

cal i  ber 

def num 

f  i  red. at 

foe 

hi  t .state 

k.hi  t 

m.d 

mki  1  1 

ncase 

num  .  he . 1 e  f  t 

red. 1 .const  ant 

t  ank 

won • type 

y  .current 


WRITES  : 


CALLS  : 


cal i ber 
f.d  - 
f  ki  1  1 

h  i  t . state 
kki  1  1 
mf  ki  1  1 
name 
num .hit 
time.v 
x  .current 
z  .current 


abs.  f 

1  oc 

uni  f orm . f 


y .  1  oc 


i  d . red ,bt ry 

ok 

t  yoe • ammo 

x  .  1  oc 


arty.pk.table 

debuq 

f.d 

fki  1  1 

aunt  ube 

kki  1  1 

mf ki 1 1 

name 

no .msns . f i  red 

num  .hit 

spd 

time.v 

x  .current 

z .  cur  rent 


de  f num 

f  i  red. at 

gunt  ube 

k.hi  t 

m.d 

mki  1  1 

ncase 

sod 

t  ype . ammo 

y .current 


at  ri  t 
t  racer 


SCHEDULED  BY  : 

i  mpac  t 
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MRL. IMPACT  Ccont) 

COMPLEXITY  :  Execution  time  is  linear  on  tanks  in  blue. alive 
and  storage  is  constant. 

REMARKS    :    Local    variable    no .mens . f i red    should    be 
no  .msns • f  i  red. 

NEW. COORD  I  NATE. SYSTEM 


PARAMETERS  : 

angl  e 
yol  d 

LOCAL  VARIABLES 
angl  e 
xol  d 
yol  d 


CALLS  : 


cos .  f 
t  racer 


CALLEO  BY  : 

assessment 

COMPLEXITY    :    Constant 
requ  i  rement  s . 


NUMBER  BYTES  OBJECT  CODE 


xold 


xnew 
ynew 


s  i  n  .  f 

error 
execut  i  on    time 


88 


and 


a56 


s t o  rage 


REMARKS  :  Yielding  xnew  and  ynew 

NEtf.FO 
NUMBER  BYTES  OBJECT  CODE 

PARAMETERS  : 

a 


LOCAL  VARIABLES  : 

bl ue .al i  ve  co 

fa  pi t . 1 dr 

tank  type 

SCHEDULED  BY  : 

i  mpact 

COMPLEXITY  :  Execution  time  is  linear  on  tank  in   blue. alive 
with   co(tank)  =  co(a)»  until  tank  =  pi t 1 dr ( t ank ) . 

Storage  requirements  are    constant. 
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PARAMETERS  : 

start 

LOCAL  VARIABLES  : 
start 

GLOBAL  VARIABLES  : 
name 


NEW. FORCES 
NUMBER  BYTES  OBJECT  CODE  :  128 

StOD 

St  OD 


RELEASES  : 


CALLS  : 


bbbpoi  nt 
r r rpo  i  nt 


red.c  reate 


red .c  reate 


SCHEDULED  BY  : 
ma  i  n 

COMPLEXITY    :    Constant    execution    time    and 
requ  i  remen t  s . 


st  orage 
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PARAMETERS  : 

a 

i  d .m  i  ss  i  on 

LOCAL  VARIABLES  : 

a 

di  stance 

err  .2. 

err  .4 

err  .6 

er  r .  8 

i  d. f dc 

i  d.mi  ss  i  on 

x.l 

x.3 

GLOBAL  VARIABLES  : 

di  r .apparent 

error .code 

sod .aooarent 

x.curl 

y .cur4 

CALLS  : 

arctan . f 

di  st 

posi  t  i  on .update 

t  racer 

NEW. LOCATION 
.NUMBER  BYTES  OBJECT  CODE  :  1384 

del . t  i  me 


del  . t  i  me 
err .  1 
err.  3 
err  .5 
err  .7 
i  d.bt  ry 
i  d.  f  o 
tank 
x.2 

X  X 


di  rec t  i  on 

mi  ss  i  on 

type 

x . future. 1 oc 

y . future. 1 oc 


cos .  f 

fa.tgt .error 

s  i  n  .  f 


CALLED  BY  : 

arty. impact  updat e .c 1  us t er 

COMPLEXITY    :    Constant    execution    time    and    storage 
requ  i  rement  s . 
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NEW. MISSION 
NUMBER  BYTES  OBJECT  CODE 


1432 


PARAMETERS 


i  d.  f  o 

name .priori  t  y 

LOCAL  VARIABLES  : 
a 
m 
priority 

GLOBAL  VARIABLES  : 

amt . i  n .c 1 ust  ers 

di  rect  i  on 

f o. tgt . range 

mission 

no .c 1 usters 

pr i ,of .cluster 

t  i  me .of . updat  e 

x.cur" 


WRITES 


a 

i  d.  f  o 

soeed 
y  ,cur4 


CREATES 
CALLS  : 
CALLED  BY 
COMPLEXITY 


mi ss i on 


di  st 


uDdat e.c 1 uster 

:    Const  ant 
requ  i  recent  s • 


or i  or i  t  y 

i  d.  f  o 

name .priori  t  y 


clusters 
f  i  st 
1  count 
msn .name 
po  i  nt  i  ng. to 
speed 
t  i  me. v 
y  .cur4 


di  rect  i  on 

msn . name 
x .cur4 


t  racer 


execut  i  on 


t  i  me 


and 


storage 
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OPEN.RADIO.NET 

NUMBER  BYTES  OBJECT  COOE  :  240 

PARAMETERS  : 

i  d  .  r  a  d  i  o 

LOCAL  VARIABLES  : 
i  d  .  r  a  d  i  o 

GLOBAL  VARIABLES  : 
state3 

CALLS  : 

t  racer 

SCHEDULED  BY  : 

arty. impact  commo .at t emot 

end. of »mi ss i on  guns.firinq 

COMPLEXITY    :    Constant    execution    time    and    storage 
requ  i  rement s  . 
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PARAM.SET 

NUMBER  BYTES 

OBJECT  CODE 

PARAMETERS  : 

a 

LOCAL  VARIABLES  : 

a 

aname 

weaoonry 

GLOBAL  VARIABLES  : 

c  .bar 

cbar 

defnum 

d  i  r . mvmt 

d  •  num 

m.det 

micro 

mine.det 

mv  .  t  i  me 

name 

p. hat 

pi .hat 

Pi  .c 

p 1 ow .cond 

P.  v 

sod 

t  i  me  .  v 

t  .spd 

v.ms 

won • t  yoe 

x  .Ct 

x  .current 

y  .ct 

y  .current 

z.ct 

z  .current 

zh 

920 


CALLS 


move 


CALLED  BY  : 

1  oc 

COMPLEXITY  :  storage  requirements   and   execution   time  are 
const  ant  . 
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PARAMETERS  : 

J 

rg 

LOCAL  VARIABLES  : 
count 
del ta.2 
i 
k 
s  i  g.df 


PARAMETERS 
NUMBER  BYTES  OBJECT  CODE  :  1128 

k 

type .ammo 


del ta. 1 

f  ract  i  on 

J 

rg 

s  i  g. rg 


GLOBAL  VARIABLES  : 

no . range .bands 


CALLS  : 


t  racer 


CALLED  BY  : 

assessment 


range .bands 


error 


COMPLEXITY  :  execution   time   is   linear   depending   on   the 
number  of  range  bands.  Storage  is  constant. 

REMARKS  :  This  routine   returns   the   value   of   sig.rg   and 
si g.df  to  the  calling  routine. 
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POP. A. MINE 


NUMBER  BYTES  OBJECT  CODE  :1760 


PARAMETERS  : 

tnk 

LOCAL  VARIABLES  : 
e  f  k  i  1  1 
jo 
tnk 
whoca 1 1 ed 


type 


emk  i 1 1 
kayki 1 1 
tyoe 


GLOBAL  VARIABLES  : 

damage .num 

de  f num 

f i red. at 

guntube 

k.hi  t 

m  .d 

mi  n 1 et  h 

mk  i  1  1 

ncase 

pi ow  .cond 

sod 

won . type 

y  .current 


dam .  array 
f  .d 
fkill 
hi  t .state 

kki  1  1 
mf ki 1 1 

name 
num .hit 

t  i  me . v 
x . current 
z .  current 


WRITES 


de  f num 

f  i  red. at 

guntube 

k  .  h  i  t 

m.d 

mki  11 

ncase 

spd 

wpn . type 

y  .current 


f.d 

fkill 

hi t .state 

kki  1  1 
mf ki  1  1 
name 
num .hit 
t  i  me  .  v 
x . current 
z .current 


CALLS 


at  ri  t 


CALLED  BY  : 

convert .back 

COMPLEXITY  :  Storage  requirements   and   execution   time  are 
const  ant . 
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POSITION. UPDATE 
NUMBER  BYTES  OBJECT  CODE  :  1104 


PARAMETERS  : 

a 

LOCAL  VARIABLES  : 
a 

i  d.mi  ssi  on 
tank 
y  .bar 

GLOBAL  VARIABLES  : 

b .org. a  1 i  ve 

di  rect  i  on 

name 

red. a  1 i  ve 

speed 

t  i  me. v 

x .current 

y  .cur  rent 


CALLS 


CALLED  BY 


cos .  f 

sin.f 


arty  .  i mpac t 
new .location 


i  d . m  i ssion 


i  d.  f  o 
spd.bar 
x  .  ba  r 


C  .number .array 

f  i  st 

no.clusters 

spd 

stated 

t .pos  i  t  i  on 

x .cur4 

y .cur4 


1  oc 

t  racer 


error 


COMPLEXITY  :  Storage  reauirements  are  constant.  Execution  is 
linear  on  tanks  in  red. alive. 
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PARAMETERS  : 

a 
c 

e 

LOCAL  VARIABLES 
a 

c 
e 
i 
k 


PREPLANNED 
.NUMBER  BYTES  OBJECT  CODE  :  1008 


b 

d 

f 

'l 


GLOBAL  VARIABLES  : 

red.pl anned.fi  res 

CALLED  BY  : 

f a  .  1 .ma  i  n 

COMPLEXITY    :    Constant    execution    time    and 
requi  rement  s . 

PRINT 

NUMBER  BYTES  OBJECT  CODE  :  336 


PARAMETERS: 

i  d.mi  ssi  on 

LOCAL  VARIABLES  : 
debug 
rad.er r 
x  .  future. \ oc 
y  .  future . 1 oc 


i  d  . mi  s s  i  o n 

x.cur^l 
y  .curU 


WRITES  : 


CALLS  : 


rad.err 


di  st 


CALLED  BY  : 

arty,  i  rnoac  t 


assessment 


COMPLEXITY    :    Constant    execution    time    and 
requi  rement  s . 


storage 


s  t  o  rage 
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PRINT1 
NUMBER  BYTES  OBJECT  CODE 


1  12a 


PARAMETERS  : 

i  d  .m  i  ssion 

LOCAL  VARIABLES  : 
i 

i  d .m  i  ss  i  on 
tank 

GLOBAL  VARIABLES  : 

b .org. a  1  i  ve 

debug 

name 

rd.of  f set 

red. alive 

tank 

x .current 

y .curU 

y . future. 1 oc 


WRITES 


CALLED  BY 


1 

name 

x ,cur4 

x . f uture . 1 oc 

y .current 


arty . i moac t 


i  d.  f  o 
i 


c  .  number .array 

f  i  st 

no.c 1 uster 

stated 

x  .  cur4 

x  •  future. 1 oc 

y .  current 


J 

rd.of  f set 

x  .current 

y  .  cur4 

y . f ut  ure  .  1 oc 


assessment 


COMPLEXITY  :  Execution  time  is  linear  on  tank 
and  storage  is  constant. 


i  n   red . a  1  i  ve 
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PRIORITY. AND. ROUND. SELECT 
NUMBER  BYTES  OBJECT  CODE  :  1336 


PARAMETERS  : 
a 

LOCAL  VARIABLES  : 
a 
0 

i 

rnd 

GLOBAL  VARIABLES  : 
b  1  ue 
dsl 
wdo . t  vpe 


CALLS  : 


ammo .check 


answer 

i 

p 

t  h  reshol d 


color 
range 


t  rune  •  f 


CALLED  BY  : 

target . sel ec t 

COMPLEXITY    :    Constant    execution    time    and    storage 
regu  i  rement  s . 

REMARKS  :  Returns  the  value  of  o   and   rnd   to   the   calling 
rout  i  ne  • 
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PROXIMITY. DETECT 

.  NUMBER  BYTES  OBJECT  CODE  :  864 

PARAMETERS  : 

a  b 

LOCAL  VARIABLES  : 

a  b 

whocallea  x. sample 

y . samol e 

GLOBAL  VARIABLES  : 

alive .dead  bl ue 

color  ol t 

pi t .uni t  tank 

x. current  y. current 

CALLS  : 

abs. f  list. update 

CALLED  BY  : 

detect 

COMPLEXITY  :  Execution  time  is  linear  on   tank   in   pit. unit 
and  storage  is  constant. 
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RED. CREATE  . 
NUMBER  BYTES  OBJECT  CODE  :  2a08 


PARAMETERS  : 

a 

LOCAL  VARIABLES 

a 
i 

GLOBAL  VARIABLES 
ap .  tow 


READS 


CREATES 
FILES  : 
RESERVES 


bbbpoi  nt 

bn 

c  .number .array 

cocdr 

di  r .o  f .mvmt 


array .detect 

be .count 

b .num . a  1 i ve 

CO 

def num 
1  i  st 


max. number. of. mi  ssions.oer.fo 


mv  .  stat e 

n  .  f  o 

pi  .c 

pTt 

poi  nter 

sod 

target 

won . type 

y  .current 


On 
cocdr 

p1t 

won .type 

y  .current 


name 
OP. rng 
pi ow .cond 
pi t 1 dr 
or i  .di  r 
t  ank 
t  i  me  .  v 
x  .cur  rent 


CO 

name 

ol t 1 dr 

x  .current 


t  ank 


tank  in  tanks*  red.al ive>  comp.unit  and  pit. unit 


array .detect 
1  i  st 


c  .  number .array 
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RED. CREATE  (cont) 


RELEASES  : 


array .detect 


c . number .array 


CALLS  : 


basi  c . 1 oad 
set . sector 


h  i  der 


CALLED  BY  : 

new .forces 

SCHEDULES  : 

1 oc .uodat  e 

COMPLEXITY  :  Execution  is  dependent  on  input  parameters  a 
and  br  main  loop  will  be  executed  b-a+1  times  per 
invocation.  Storage  is  dependent  on  be. count* 
n.fo  and  max . number . o f .m i ss i ons .per . fo . 
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RED. ARTY. FIRES 


NUMBER  BYTES  OBJECT  CODE  :  3368 


PARAMETERS  : 

i  d. red.bt  ry 

LOCAL  VARIABLES  : 
i 

i  terat  i  on 
red.  2.  .constant 
x 


i  terat  i  on 


i  d. red.bt  ry 

ok 

t  ype . ammo 


GLOBAL  VARIABLES  : 

a  1 i  ve.dead 

b  1  u  e .  a  1 ive 

def num • 

f  i red. at 

foe 

hi  t .state 

kkil  1 

m.d 

mki  1  1 

ncase 

no  .msns • f  i  red 

num . guns 

num .hit 

red.pl anned. f  i  res 

sa 1 vos 

tank 

won .type 

y .current 


arty.pk.table 

cal i  ber 

f  .d 

fki  1  1 

quntube 

k  .hi  t 

kount 

mf ki  1  1 

name 

num .do  i  cm . 1 ef  t 
num . he . 1 ef  t 

rn . st  ream 

spd 

t  i  me . v 

x  .  current 

z  .cur  rent 


WRITES  : 


cal i  b  e  r 

f.d 

fki  1  1 

h  i  t . st ate 

kki  1  1 
m  f  k  i  1  1 
name 
num  .hit 
t  i  me.  v 
x .current 
z .current 


de  f  num 

f  i  red. at 

qunt  ube 

k  .hi  t 

m.d 

mki  1  1 

ncase 

spd 

t  ype . ammo 

y  .cur  rent 
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RED. ARTY. FIRES  (cont) 


CALLS  : 


atri  t 
t  racer 


1  oc 

un i f orm . f 


SCHEDULES  : 

red. art y . f  i  res 

SCHEDULED  BY  : 

f a . 2  .ma  i  n 


red .arty.fi  res 


COMPLEXITY  :  Storage  requirement  is  constant.  Execution  time 
is  deoendent  on  the  Droduct  of  salvos  and  tanks  in 
blue.al ive. 
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RELOAD 

NUMBER  BYTES  OBJECT  CODE  :  2736 

PARAMETERS  : 
a 

LOCAL  VARIABLES  : 
a 

GLOBAL  VARIABLES  : 

bt  i  me  c  .  I 

c.2  capds 

case  cda 

cdh  cdt  i  me 

cheat  erf 

def num  def . t  i  me 

gunt  ube  i  n  i  t 

r .con  s 1 . t  i  me 

s2 . t  i  me  veh . t  yoe 

CALLED  BY  : 

h  i  de 

SCHEDULES  : 

h  i  de 

COMPLEXITY    :    Constant    execution    time    and    storage 
requ  i  remen t s • 

RES1 

NUMBER  BYTES  OBJECT  CODE  :  252 

GLOBAL  VARIABLES  : 

hnorm  norseed 

READS  : 

norseed 

RESERVES  : 

hnorm  norseed 

CALLED  BY  : 

ma  i  n 

COMPLEXITY    :    Constant    execution    time    and    storage 
requ i  rement  s  . 
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RES2 

. NUMBER 

BYTES  OBJECT  CODE 

GLOBAL  VARIABLES  : 

accbm 

accht 

accke 

accms 1 

addon 

bm .mov 

bushbmp 

dgnv 

h t .mov 

ke .mov 

lei  1 

lel2 

le31 

1  e61 

le71 

1e72 

led! 

-le82 

mi  n 1 et  h 

sovmg 

t ardi  m 

usmg 

RESERVES  : 

accbm 

accht 

accke 

accms 1 

addon 

bm  .mov 

bushbmp 

dgnv 

ht .mov 

ke .mov 

1  el  1 

lel2 

le31 

le61 

le71 

le72 

1e81 

le83 

mi  n 1 et  h 

sovmg 

t ardi  m 

usmg 

CALLED  BY  : 

ma  i  n 

2000 


COMPLEXITY    >         Constant    execution    time    and    storage 
regu  i  rement  s  . 

REMARKS  :  Rearrangement   of   subscripts   will   provide   more 
efficient  storage  utilizing  fewer  pointers. 
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LOCAL  VARIABLES 
i 

k 
m 

GLOBAL  VARIABLES 
lell 
le31 
1e71 
le81 


RES3 
NUMBER  BYTES  OBJECT  CODE 


3336 


lel2 

le61 

1e72 

.1e83 


CALLED  BY 


ma  1  n 


COMPLEXITY    :    Constant 
requi  rement  s  . 


execution 


t  i  me 


and 


s  t orage 


REMARKS  :  Rearranging  loops  to  avoid   duplication   will   cut 
the  number  of  "for"  looos  from  11  to  6. 


LOCAL  VARIABLES 
i 
k 

m 

GLOBAL  VARIABLES 
accht 
accms 1 
dgnv 

ke .mov 

CALLED  BY  : 

ma  i  n 


RESa 
NUMBER  BYTES  OBJECT  CODE 


ace  ke 
addon 
h t . mov 

t  a  rdi  m 
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COMPLEXITY    :    Constant 
requ  i  rement  s  . 


execution    time    and    storage 
REMARKS  :  Combine  7  "for"  looos  with  i=l  to  2  into  1  loop. 
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RES5 

NUMBER  BYTES  OBJECT  CODE  :  48 

CALLED  BY  : 

mai  n 

REMARKS  :  This  routine  does  nothing. 

SECTOR. CHECK 

NUMBER  BYTES  OBJECT  CODE  :  608 

PARAMETERS  : 

a  b 


LOCAL  VARIABLES  : 
a 
b 

c . ri  ght 
x  .  t 

GLOBAL  VARIABLES  : 
area 
x  .current 


CALLS  : 


abs  •  f 


answer 
c. 1  eft 

r 
y.t 


const  ant 
y  .current 


sgrt . f 


CALLED  BY  : 

i  mpact  st ep . t  i  me 

COMPLEXITY  :  Constant  storaae  and  execution  time. 

SET. MUZZLE. VEL 

NUMBER  BYTES  OBJECT  CODE  :  a00 

PARAMETERS  : 
a 

LOCAL  VARIABLES  : 
a 

GLOBAL  VARIABLES  : 
mz 1  .  vel 

CALLED  BY  : 

f  i  re 

COMPLEXITY  :  Constant  storage  and  execution  time. 
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SET. SECTOR 
NUMBER  BYTES  OBJECT  CODE 


a48 


PARAMETERS  : 

t  ank 

LOCAL  VARIABLES 
a 

t  ank 
x 

GLOBAL  VARIABLES 
pi  .c 


b 

width 

y 


CALLS  : 


cos.  f 


CALLED  BY  : 

chg. sec .search 
di  smount  .dragon 
red.creat  e 


s  i  n  .  f 


defend 
ma  i  n 


COMPLEXITY  :  Constant  storage  and  execution  time. 

SIGHT 
NUMBER  BYTES  OBJECT  CODE 


712 


PARAMETERS  : 

a 
b 

GLOBAL  VARIABLES  : 
bwd .look 
hto 
name 
pea . v  i  s 
peb .vis 
y .  current 


aname 
bname 


f wd . 1 ook 
m  i  c  ro 
pea  .unc 
peb  .  unc 
x  .current 
z  .current 


CALLS 


1  OS 


CALLED  BY  : 

commo .pass . t gt 

f  i  re 

st  ep . t  i  me 


m  i  n  .  f 


det  ect 
i  mpac t 
t  arget  .select 


COMPLEXITY  :  Constant  storage  and  execution  time. 
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STEP. TIME 
NUMBER  BYTES  OBJECT  CODE 


PARAMETERS  : 
a 

LOCAL  VARIA8LES  : 

a 

bdet .  t  i  me 

r 
rn  .b 

GLOBAL  VARIABLES  : 

a  1  i  ve.dead 

Dwd. 1 ook 

del ta.t 

f .b 1 ue .a  1 i ve 

name 

pcb  .unc 

steps 

tgt sc 1 

w  .  k  .  c  . 

y  .current 


RESERVES 
RELEASES 
CALLS  : 


SCHEDULES 


1  i  st 


1  i  St 


cardi  o 
di  sr 

sector .check 
t  racer 


detect 


SCHEDULED  BY  : 
ma  i  n 


answer 
1  ose 

rdet .time 
rn.r 


answer 

def num 

fa 

f wd . 1 ook 

OD . rng 

PC  t  .  v  i  s 

t  a  rget 

t  i  me  .  v 

x  .current 


166a 


chg  .  sec . sea  re  h 

m  i  n  .  f 

s  i  ght 

uni f o rm  .  f 


step  .  t  i  me 


st ep . t  i  me 


COMPLEXITY  :  Storage  is  constant.  Execution  time  is  linearly 
dependent  on  the  number  of  tanks  in  red. alive. 
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STOP. SIMULATION 


NUMBER  BYTES  OBJECT  CODE  :  4396 


GLOBAL  VARIABLES  : 

attributes  of  every  fo 

attributes  of  every  cattery 

attributes  of  every  fdc 

attributes  of  every  mission 


in  msn, queue 


attributes  of  every  mission  in  holdinq.msns 


al i  ve.dead 
awl .or ,ms 1 3 
be .count 
c.l 

CO 

de  f num 

f  .d 

f  i  red. at 

he  .drag 

k.hi  t 

1  in 

m  .d 

mf  .hi  t 

mki  1  1 

name 

n .bl ue .a  1 i  ve 

num  .hit 

Pit 

r  .con 

sec 

spd 

t  i  me. v 

t  .  SDd 

x  .cur rent 

z  .current 


ap. t ow 
bn 

-c.2 
erf 

di  r . o f .mvm t 
f  .hi  t 
fki  )  1 

h  i  t .st  at e 
kki  11 

m  .  h  i  t 
mf ki 1 1 
mv • st at e 
nd. h  i  t 
n . red . a  1 i  ve 
d 1 ow. cond 
or  i  .di  r 
re  .count 

tank 

trf 

wpn . t  yoe 

y  .current 
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STOP. SIMULATION  (cont) 


WRITES 


at  t  r  i  butes 
at  t  r i  butes 
at  t  pi  butes 
attributes 
attributes 
a  1 i  ve.dead 
awl  .or.msl 3 
be .count 
c.l 

CO 

de  f num 

f.d 

f  i  red. at 

he  .drag 

k.hi  t 

1  in 

m  .d 

mf  .  h  i  t 

mki  1  1 

name 

n  .b 1 ue  .a  1 i ve 

num .hit 

pit 

r  .con 

sec 

SDd 

t  i  me . v 
t  .sod 
x  .  cu  r  rent 
z  .current 


of  every  f o 

of  every  battery 

of  every  fdc 

of  every  mission  in  msn. queue 

of  every  mission  in  holding. msns 

ap .  tow 

bn 

c.2 

'   erf 

di  r .of . mvmt 
f  .hi  t 
fkil  1 

hit. state 
kki  1  1 

m  .  h  i  t 
mf ki 1 1 
mv  .  st  at  e 
nd.  h  i  t 
n.red.al ive 
pi ow .cond 
or  i  .di  r 
re  .count 

t  ank 

trf 

wpn  .  t  ype 

y.cu r rent 


CALLS  : 


1  oc 


SCHEDULED  BY  : 

at  t  r i  t  i  on .check 


main 


COMPLEXITY  :  Execution  time  is  linear  on  tanks   and   storage 
i  s  constant . 
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PARAMETERS  : 
a 

LOCAL  V4RIABLES  : 
a 

GLOBAL  VARIABLES  : 
bl  ue 
P  r  o  j  o 
sod 
t  .spd 

CALLED  BY  : 

fire 


STOP. TO. FIRE . 
NUMBER  BYTES  OBJECT  CODE  :  368 

st opcount 

s topcount 


color 

second. shot 
't  i  me  .  v 


i  nnoac  t 


COMPLEXITY    :    Constant    execution    time    and 
requi  rement  s . 


storage 
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SUBCAL 
NUMBER  BYTES  OBJECT  CODE 


PARAMETERS  : 

f .pcv  i  s 

p 

tgt  .t 

LOCAL  VARIABLES  : 
efki 1 1 
emk  i  1 1 
f .pcv  i  s 
i  o 
jo 

kayo  1 
mo 

nh  i  t 
phi  t 
ro 

tgt  .t 
whoca 1 1 ed 

GLOBAL  VARIABLES  : 
bushbmp 
dgnv 
p  r  o  j  o 
spd 
using 


WRITES 


CALLS 


CALLED  BY 


pro  jo 

b  i  nomi  a  1  .  f 

sovmg 

usmg 

compute 


oc  .  v  i  s 
sh.t 


efol 
emo  1 
i 
J 

kavki  1  1 

1 

n 

pc  .  v  i  s 

r 

sh.t 

vel 


damage . num 

Dh 

sovmg 

t  a  rdi  m 

wpn . t  yoe 


wpn . t  ype 


bushbmp 
t  rune  .  f 


4040 


COMPLEXITY  :  Execution  time  is  linear  on  nhit  and  storage  is 
constant . 
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T72. TACTICS  . 
NUMBER  BYTES  OBJECT  CODE  :  1216 

PARAMETERS  : 

a 

LOCAL  VARIABLES  : 

a  aim 

answer  lose 

resu 1 t  time 
x 

GLOBAL  VARIABLES  : 

alive. dead  bwd.look 

check .time  cocdr 

c  r i  t  i  cal  .  val ue  foe 

f wd. I ook  dc t  .  v  i  s 

pltldr  pro  jo 

sched  tank 

t  i  me .a  t  i  me  .  v 


CALLS  : 


ammo. check  commo .pass . t gt 

exp. f  1  ay . 1 oad 

1  oc 

CALLED  BY  : 

target .sel ec  t 

SCHEDULES  : 

fire 

COMPLEXITY  :  Execution  time  is  linear  on  tank  in  pit. unit 
and  storage  reguirements  are    constant. 

REMARKS  :  Returns  the  value  of  answer  to  the  calling 
routine.  By  initializing  answer  to  1  instead  of 
Or  two  "if"  seguences  may  be  eliminated  resulting 
in  11  fewer  lines  of  source  code. 
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TALLY. HIT. STATE 
NUMBER  BYTES  OBJECT  CODE  :  1856 


PARAMETERS  : 

damage .num 

LOCAL  VARIABLES  : 

damage . num 

GLOBAL  VARIA8LES  : 
bl  ue 

CO 

comp  .unit 

f  .hi  t 

k.hi  t 

m.b 1 ue.al i  ve 

m.h  i  t 

no  .h  i  t 

Pit 

red. alive 


tank 


tank 


b 1 ue . a 1  i  ve 
color 

f  i  red. at 
1  i  st 
mf  .  h  i  t 
name 
n  u  m  .  h  i  t 
pi t .un  i  t 
t  arget 


REMOVES 


tank  from  blue. alive  or   red. alive/   pit. unit   and 
como .unit 


RELEASES  : 


CALLS  : 


1  i  st 


1 eave.chec  k 


CALLED  BY  : 

final .deat  h 


i  mpac t 


COMPLEXITY    :    Constant    execution    time    and    storage 
reau  i  remen t  s  . 
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TARGET. SELECT 


NUMBER  BYTES  OBJECT  COOE 


2592 


PARAMETERS 


LOCAL  VARIABLES  : 
a 

answer 
i 

old, range 
P 

rnd 
whoca 1 1 ed 


a  i  m 

engaged 
id 
ol  dp 

r 

time 

x 


GLOBAL  VARIABLES  : 

alive .dead 

bwd. 1 ook 

color 

def num 

fip 

fki  1  1 

f wd. 1 ook 

1  i  st 

name 

po  i  nt  er 

range 

target 

t  i  me . v 

x .current 


blu 
che 
c  r  i 
fa 
f  i  r 
foe 
1  in 
mv  . 
oc  t 
pro 
sch 
t  i  m 
won 
y  .c 


c  k . t  i  me 

t  i  ca 1  .value 


e. of. sight. exists 

state 

.vis 

jo 

ed 

e  .a 

.  t  yDe 

ur rent 


CALLS  : 


bmp. t ac t  i  cs 

di  st 

h  i  der 

itv.tactics 

1 i  st .update 

priori  ty. and. round. sel ect 

1 72. t ac t  i  cs 


di  m .  f 

exo .  f 

i  fv. tactics 

1  ay . 1 oad 

1  oc 

sight 

xm 1  .  t  ac  t  i  cs 


SCHEDULES  : 

f  i  re 


SCHEDULED  BY  : 

1 i  st  .update 
we  .m  i  ss 


we  .  h i  t 


COMPLEXITY  :  Constant  storage  and  execution  time. 
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TRACER 


NUMBER  BYTES  OBJECT  CODE  :  304 


PARAMETERS  : 

a 

LOCAL  VARIABLES  : 
a 


GLOBAL  VARIABLES  : 

t ime.v 

WRITES  : 


CALLED  BY 


tr.time 


f i  me.  v 


arty. impact  arty. time 

busy . radi  o.net 
checkinq.quns.avai 1  aO  i 1 i  ty 


commo.at  tempt 

ena.of .mi  ssi  on 

f a . tgt .error 

fire 

i  mpact 

new.coordinate.system 

new  .mi  ss  i  on 

parameters 

red. arty . f  i  res 

uDdat e.c luster 


detect 
error 

f dc .process  i  ng 
puns .firing 
mr 1  .  i  moac  t 
new .location 
open . radi  o .net 
pos  i  t  i  on .update 
s t  ep . t  i  me 


COMPLEXITY 


Constant  storage  and  execution  time. 


200 


UPDATE. CLUSTER 

NUMBER  BYTES  OBJECT  CODE  :  2256 

PARAMETERS  : 

i  d  .  f  o 

LOCAL  VARIABLES  : 

est i mat e .of . t i me  id.fo 

i  d .mi  ss  i  on  m 

name .or i or i t y  pri .value 

t  i  me. 1  t  i  me  .2 

GLOBAL  VARIABLES  : 

amt . ac t i ve .msns  afflt.msns.fi  red 

busy  debug 

1 ast .c 1 ustered  msn.time 

max. number. of. missions. oer.fo 

stated  t  i  me.  v 


WRITES 


CALLS 


id.fo  time.v 


arty. time  do i ng .c 1 ust ers 

new. location  new. mission 
t  racer 

SCHEDULED  BY  : 

fa. 2. main  fo. not. busy 

COMPLEXITY  :  Constant  storage  and  execution  time 

VALS. FOR. CASE 

NUMBER  BYTES  OBJECT  CODE  :  712 

GLOBAL  VARIABLES  : 

ba  bh 

capds  case 

caseap  casehe 

cda  cdh 

cheat  guntube 
i  n  i  t 

CALLED  BY  : 

ma  i  n 

COMPLEXITY  :  Constant  storage  and  execution  time. 
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WE. HIT 
NUMBER  BYTES  OBJECT  CODE  :  1328 


PARAMETERS  : 
a 

LOCAL  VARIABLES  : 

a 

GLOBAL  VARIABLES  : 
ao. tow 
aw2  .or .adm 
c.2 
foe 

h  i  t  shot 
r  .con 
won  .  t  ype 


CALLS  : 


h  i  der 


awl  .or  .ms 1 3 
c.l 

defnum 
he. drag 
mi  ssshot 
r  .count 


CALLED  BY  : 

i  mpact 

SCHEDULES  : 

nide  t arget . sel ec t 

COMPLEXITY  :  Constant  storage  and  execution  time 
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WE. MISS 
NUMBER  BYTES  OBJECT  CODE 


1808 


PARAMETERS  : 
a 

LOCAL  VARIABLES 
a 

r 
x 

GLOBAL  VARIABLES 
ap. tow 


CALLS 


aw2  .or .adm 

c.2 

cie  fnum 

he  .drag 

mi ssshot 

range 

sched 

t  i  me  .  v 

x .current 


ammo .chec  k 

exp.  f 

1  ay . 1 oad 


CALLED  BY 
SCHEDULES 


i  mpac  t 


f  i  re- 

t  arget . se 1 ec t 


answer 
t  i  me 


aw  1  .or .ms 1 3 

c.l 

chec  k . t  i  me 

foe 

h  i  t  shot 

oro  j  o 

r  .con 

time.a 

won . t  ype 

y  .current 


di  st 

h  i  der 


h  i  de 


COMPLEXITY  :  Constant  storage  and  execution  time. 
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XM1 .TACTICS 
NUMBER  BYTES  OBJECT  CODE  :  352 


PARAMETERS  : 

a 

LOCAL  VARIABLES  : 

a 
b 

GLOBAL  VARIABLES  : 
foe 
pi t .uni  t 


CALLS  : 


uni  forin.f 


answer 

z 


pit 

tank 


CALLED  BY  : 

t  arqet .sel ec  t 

COMPLEXITY  :  Storage   is   constant.   Execution   is   linearly 
dependent  on  the  number  of  tanks  in  pit. unit. 
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APPENDIX  C 


ROUTINE 


LINES   START 


END 


BYTES 


SIMSCRIPT  ROUTINES 


ma  1  n 

h  i  der 

res  1 

res2 

res3 

res4 

res5 

red  .c  reate 

bl .c  reate 

new .  forces 

s  i  ght 

convert .back 

param  .set 

bas  i  c . 1 oad 

va 1 s . f or .case 

re  1 oad 

bug. check 

dr .mount 

d  i  smount  .dragon 

df  .chg 

defend 

st ep . t  i  me 


95 

ba028 

bb750 

5928 

10 

-  bb750 

bb890 

320 

3 

bb890 

bb978 

232 

2a 

bb978 

bcl48 

2000 

37 

bcl48 

bce50 

3336 

18 

bce50 

bd5c8 

1912 

2 

bd5c8 

bd5f8 

48 

a3 

bd5f8 

bdf60 

2408 

46 

bdf60 

beatoS 

2824 

5 

bea68 

bebe8 

128 

9 

bebe8 

beebO 

712 

17 

beebO 

bf  178 

712 

21 

bf  178 

bf510 

92  0 

27 

bf510 

bfd38 

2088 

10 

bfd38 

cOOOO 

712 

40 

cOOOO 

cOabO 

2736 

12 

cOabO 

cOebO 

1024 

18 

cOebO 

C1358 

1192 

12 

C1358 

cl640 

744 

14 

C1640 

C1830 

496 

12 

cl830 

claeO 

688 

65 

claeO 

c2660 

1664 
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ROUTINE 


LINES   START 


END 


BYTES 


detect 

target . sel ect 

f  i  re 

1 eave.chec  k 

charge 

get .ud 

i  mpac  t 

1 oc  .update 

st op  .  s  i  mu 1  at  i  on 

c  a  p  d  i  o 

list  .update 

prox  i  m  i t  y .det ec  t 

commo .pass . tgt 

t  72.  tact  i  cs 

i  f v  .  tac t  i  cs  — 

xml . t  act  i  cs 

bmp. tac t  i  cs 

i  tv.tactics 

set .muzz  1 e. vel 

priority. and. round. select 

ammo .chec  k 

decrement .ammo 

we .mi  ss 

we. h  i  t 

stop. to. f  i  re 

1  ay  .  1 oad 


•  ***•*■ 

•  ••WM 

^mm^ 

21 

c2bb0 

c2978 

792 

7a 

C2978 

C3398 

2592 

51 

C3398 

c3c50 

2232 

112 

c3c50 

C6278 

97b8 

a7 

C6278 

c6ae0 

2152 

12 

c  6  a  e  0 

cbd20 

57b 

89 

c6d20 

c  7ea8 

4488 

6 

c7ea8 

C8028 

384 

27 

c8028 

c90f  0 

429b 

55 

c90f0 

c95f0 

1280 

62 

c95f0 

c9d20 

1840 

2b 

c9d20 

ca080 

Sb4 

21 

ca080 

ca2b8 

488 

27 

ca2b8 

ca778 

121b 

9 

ca778 

ca8d8 

352 

9 

ca8d8 

caa38 

352 

6 

caa38 

cab40 

2b4 

9 

cab40 

cacaO 

9b 

8 

cacaO 

cae30 

400 

49 

cae30 

cb3b8 

133b 

11 

cb368 

cb558 

49b 

13 

cb558 

cb858 

7b8 

39 

cb858 

cbfb8 

1808 

28 

cbfb8 

cc4e8 

1328 

13 

cc4e8 

cc658 

3b8 

35 

cc658 

ccea8 

213b 

20b 


ROUTINE 

LINES 

START 

END 

BYTES 

f  i  rst 

5 

ccea8 

cc  f  c8 

288 

h  i  de 

23 

ccfc8 

cd4c8 

1536 

1  oc 

23 

cd4c8 

cd910 

1096 

chg. sec . search 

25 

cd910 

cde28 

1304 

tally. hit. state 

43 

cde28 

ce568 

1856 

di  st 

a 

ce568 

ce5f8 

144 

set . sector 

12 

ce5f8 

ce7b8 

448 

sec  tor.  check 

10 

ce7b8 

cealS 

608 

at  t  r  i  ti on. check 

7 

ceal8 

cec08 

496 

compute 

91 

cec08 

cf9G8 

3528 

geom 

150 

cf9c8 

dl958 

8080 

suocal 

79 

dl958 

d2720 

4040 

a  t  r  i  t 

43 

d2720 

d2ff0 

2256 

pop. a .mine 

20 

d2f  f  0 

d36d0 

1760 

final .deat  h 

14 

d36d0 

dic60 

1424 

f  a . 1  .main 

83 

d3c60 

d4fa8 

4936 

f a .2 .ma  i  n 

44 

d4fa8 

d5d38 

3472 

f o .not  .busy 

9 

d5d38 

d5fd0 

408 

update .cluster 

46 

d5fd0 

d64a0 

2256 

commo.at  tempt 

26 

d64a0 

d68e8 

1096 

open . radi  o .net 

6 

do8e8 

d69a8 

240 

busy . radi  o .net 

6 

d69d8 

d6ac8 

240 

f dc .processi  ng 

1  10 

d6ac8 

d7828 

3424 

checking.guns.avai labi  1 i  ty 

37 

d7828 

d7f48 

1824 

guns . f  i  r i  ng 

34 

d7f48 

d8630 

1768 

art y . i  moact 

132 

d8630 

d9b50 

1312 
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ROUTINE 


LINES   START 


END 


BYTES 


end. of .mi  ssion 

do  i ng.c 1 ust ers 

assessment 

error 

red. arty.fi  res 

new.coordi  nate. system 

new. mi ssion 

parameters 

ar t  y . t  i  me 

fa.tgt .error 

new  .  1 ocat  i  on 

mr 1  .  i  mpac t 

prepl anned 

pos  i  t  i  on .update 

print 

pr  i  nt 1 

t  racer 

new . f o 

move 
i  n  i  t  rd 
setup 
1  os 
kover 
el  ev 
dy  t unx 


59 

d9b50 

da5e0 

1  14 

da5e0 

db998 

95 

db998 

dcba8 

28 

dcba8 

dcefS 

75 

dcef8 

ddc20 

8 

ddc20 

dddl8 

27 

dddl8 

de2b0 

33 

de2b0 

de718 

2a 

de718 

de8b8 

21 

de8b8 

dea58 

5a 

dea58 

defcO 

53 

defcO 

df9c8 

31 

df9C8 

dfdb8 

29 

dfdb8 

e0208 

10 

e0208 

e0358 

22 

e0358 

e08a0 

8 

e08ao 

e0970 

8 

e0970 

e0b38 

FORTRAN  ROUTINES 

ia5 

e4c88 

e5860 

73 

e0el8 

el688 

53 

e70b8 

e7508 

251 

e3260 

eac88 

ia 

ee220 

ee3f  0 

33 

e2ea0 

e31a0 

31 

efal8 

efaaO 

270a 

50a8 
a528 

9aa 

3368 

88 

ia32 

1128 

ai6 

ai6 
138a 

2568 
1008 

noa 

336 

112a 

3oa 

a56 

aoae 

2aia 

1300 

75oa 
68a 
988 

1138 
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ROUTINE 


LINES   START     END 


BYTES 


el  evg 

mcov 


38    eebeS    eef78 
24    e2b88    «2dd8 


1132 

866 


PROGRAM  TOTALS 

3842    ba028    1177e0 


382<?04 


209 


APPENDIX    D 


ROUTINE 

TYPE 

WDS 

PTRS 

OPT 

REMARK 

TOTAL 

OPTIMAL 

dgnv 

i 

16 

3 

3 

(*/2) 

19 

19 

usmg 

i 

48 

16 

16 

(*/2) 

64 

64 

sovmg 

i 

96 

33 

33 

(*/2) 

129 

129 

bushbmp 

i 

128 

47 

47 

(*/2) 

125 

125 

accms 1 

r 

224 

35 

23 

259 

247 

ke . mov 

r 

420 

83 

39 

503 

459 

accke 

r 

168 

51 

19 

219 

187 

h  t .mov 

r 

420 

83 

39 

503 

459 

accht 

r 

224 

67 

23 

291 

247 

addon 

r 

80 

7 

7 

87 

87 

accbm 

r 

84 

25 

9 

109 

93 

bm . mov 

r 

210 

41 

19 

251 

229 

t  ardi  m 

r 

198 

10 

10 

208 

208 

hnorm 

r 

1000 

1 

1 

1001 

1001 

norseed 

r 

2 

1 

0 

3 

2 

m  i  n 1 et  h 

i 

5 

10 

9 

15 

14 

tgt .acq. error 

r 

12 

3 

3 

15 

15 

tgt  sc 1 

r 

18 

1 

1 

19 

19 

mu 

r 

24 

3 

3 

27 

27 

x.ct 

r 

2 

1 

0 

3 

2 

y  .ct 

r 

2 

1 

0 

3 

2 

z  .ct 

r 

2 

1 

0 

3 

2 

v  .ms 

r 

2 

1 

0 

3 

2 
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ROUTINE 

c  .bar 

pi  .c 

m.det 

d .  num 

p. hat 

p  c  a .  v  i  s 

pcb.unc 

pcb  .vis 

Dca.unc 

P.v 

zh 

list 

target 

temp. target 

dsl 

as2 

t .dead 

i .dead 

i  t .dead 

1  el  1 

le7l 

lel2 

1e72 

le31 

le61 


TYPE   WDS    PTRS   OPT  REMARK   TOTAL  OPTIMAL 


r 

2 

0 

3 

2 

i 

1 

0 

2 

1 

i 

1 

0 

2 

1 

i 

1 

0 

2 

1 

r 

2 

-  0 

3 

2 

r 

2 

0 

3 

2 

r 

2 

0 

3 

2 

r 

2 

0 

3 

2 

r 

2 

0 

3 

2 

r 

2 

0 

3 

2 

r 

2 

0 

3 

2 

1 

0 

2 

1 

642 

322 

3 

964 

645 

150 

1 

1 

151 

151 

360 

16 

16 

376 

376 

362 

10 

10 

372 

372 

1 

1 

0 

(*/4) 

2 

1 

1 

1 

0 

(*/a) 

2 

1 

1 

1 

0 

(*/4) 

2 

1 

1470 

1  165 

691 

(*/4) 

2635 

2161 

3675 

2911 

1659 

(*/4) 

6586 

5334 

210 

167 

84 

(*/4) 

377 

294 

525 

416 

249 

(*/4) 

941 

77a 

210 

167 

84 

(*/4) 

377 

29a 

210 

167 

84 

(*/4) 

377 

29a 
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ROUTINE 


TYPE   WOS    PTRS   OPT  REMARK   TOTAL  OPTIMAL 


le81 
le83 


i    525    416    249   (*/4)    944    774 
i    525    416    249   (*/4)    944    774 
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